sReply = sReply + LEFT$(sBuff, BytesReply) 

              Last   = LEN(sReply)
              pByte = STRPTR(sReply) 
              IF Last > 5 AND @pByte[Last-1] = 10 AND @pByte[Last-2] = 13 THEN
              FOR k = 3 TO Last 
                  IF @pByte[Last-k] = 10 AND @pByte[Last-k+4] = 32 THEN EXIT DO
                  IF k = last                    AND @pByte[Last-k+3] = 32 THEN EXIT DO
             NEXT
          END IF 

        END IF 

      LOOP


The loop must be executed for each response for all the responses to be returned.

This page and the code derived from it is the result of about 60hrs reading and development testing. cryptlib is the result of years of work and can do a lot more than create an SSL tunnel. If you are interested in further reading, a good place to start is here:




Cryptlib and SSL (from the manual)


  cryptlib works with two classes of objects, container objects and action objects. A
  container object is an object that contains one or more items such as data, keys or
  certificates. An action object is an object which is used to perform an action such as
  encrypting or signing data. The container types used in cryptlib are envelopes (for
  data), sessions (for communications sessions), keysets (for keys), and certificates (for
  attributes such as key usage restrictions and signature information). Container
  objects can have items such as data or public/private keys placed in them and
  retrieved from them. In addition to containing data or keys, container objects can
  also contain other objects that affect the behaviour of the container object. For
  example pushing an encryption object into an envelope container object will result in
  all data which is pushed into the envelope being encrypted or decrypted using the
  encryption object. 

  Encryption contexts are the action objects used by cryptlib. Action objects are used
  to act on data, for example to encrypt or decrypt a piece of data or to digitally sign or
  check the signature on a piece of data.

  The usual mechanism for processing data is to use an envelope or session container
  object. The process of pushing data into an envelope and popping the processed data
  back out is known as enveloping the data. The reverse process is known as deenveloping
  the data. Session objects work in a similar manner, but are used to
  encapsulate a secure session with a remote client or server rather than a local data
  transformation. The first section of this manual covers the basics of enveloping data,
  which introduces the enveloping mechanism and covers various aspects of the
  enveloping process such as processing data streams of unknown length and handling
  errors. Once you have the code to perform basic enveloping in place, you can add
  extra functionality such as password-based data encryption to the processing. After
  the basic concepts behind enveloping have been explained, more advanced techniques
  such as public-key based enveloping and digital signature enveloping for S/MIME
  and PGP are covered.
      
  Session objects are very similar to envelope objects except that they represent a
  communications session with a remote client or server. The next section covers the
  use of session objects for protocols such as SSL, TLS, and SSH to secure
  communications or work with protocols such as CMS, SCEP, RTCS, OCSP, and TSP
  that handle functions such as certificate status information and timestamping.
  The use of public keys for enveloping requires the use of key management functions,
  and the next section covers key generation and storing and retrieving keys from
  keyset objects and crypto devices. The public portions of public/private key pairs are
  typically managed using X.509 certificates and certificate revocation lists. The next
  sections cover the management of certificates including certificate issue, certificate
  status checking, and certificate revocation list (CRL) creation and checking, as well
  as the full CA management process. This covers the full key life cycle from creation
  through certification to revocation and/or destruction.


  High-level Interface
 
  This interface requires no knowledge of encryption and digital signature techniques,
  and is easiest for use with languages like Visual Basic and Java that don’t interface to
  C data structures very well. The container object interface provides services to create
  and destroy envelopes and secure sessions, to add security attributes such as
  encryption information and signature keys to a container object, and to move data
  into and out of a container. Because of its simplicity and ease of use, it’s strongly
  recommended that you use this interface if at all possible.
      

  Initialisation
  Before you can use any of the cryptlib functions, you need to call the cryptInit
  function to initialise cryptlib. You also need to call its companion function cryptEnd
 

  The Visual Basic interface to cryptlib is otherwise mostly identical to the standard C/C++ one.

  Return Codes
  Every cryptlib function returns a status code to tell you whether it succeeded or
  failed. If a function executes successfully, it returns %CRYPT_OK. If it fails, it
  returns one of the status values detailed in “Error Handling” on page 275.       

      
  Secure Sessions - SSH, SSL, and TLS sessions,
      
  As with envelopes, cryptlib takes care of all of the session details for you so that all
  you need to do is provide basic communications information such as the name of the
  server or host to connect to and any other information required for the session such as
  a password or certificate. cryptlib takes care of establishing the session
   
  Secure sessions are very similar to envelopes, with the main difference being that
  while an envelope is a pure data object into which you can push data and pop the
  processed form of the same data, a session is a communications object into which you
  push data and then pop data that constitutes a response from a remove server or
  client. This means that a session object can be viewed as a bottomless envelope
  through which you can push or pop as much data as the other side can accept or
  provide.
 
  For example to connect to a server using
  SSH and obtain a directory of files using the ls command you would do the
  following:
  - create the session;
  - add the server name, user name, and password;
  - activate the session;
  - push data
  - pop the return
  - destroy the session
         
 
  Client vs. Server Sessions
  cryptlib distinguishes between two types of session objects, client sessions and server
  sessions. Client sessions establish a connection to a remote server while server
  sessions wait for incoming communications from a remote client.
       
  Establishing a Session
  it’s generally better to explicitly activate the session
  You can activate a session by setting its %CRYPT_SESSINFO_ACTIVE attribute to
  true (any nonzero value).
 
  SSL/TLS Sessions
  SSL and TLS are actually variations of the same protocol, the protocol known by the
  generic term SSL. cryptlib will automatically negotiate the highest protocol
  version supported by the other side.
 
  SSL/TLS is a secure data transfer protocol that provides confidentiality, integrity protection,
  protection against replay attacks, and a variety of other services. The SSL
  server is authenticated via a certificate, and the client isn’t authenticated (in rare
  circumstances client certificates may be used, but these are usually avoided due to the
  high degree of difficulty involved in working with them). Alternatively, the client
  and server may be mutually authenticated via a secret-key mechanism such as a user
  name and password, which avoids the need for certificates altogether. cryptlib
  supports SSL version 3, TLS version 1.0 (a.k.a SSL version 3.1), and TLS version 1.1
  (a.k.a SSL version 3.2).
 
  SSL/TLS Client Sessions
  Establishing a session with an SSL/TLS server requires adding the server name or IP
  address and an optional port number if it isn’t using the standard SSL/TLS port.
 
  Once you’ve added this information, you can activate the session and establish the
  connection:
 
  The Visual Basic form of the code is:
 
  Dim cryptSession As Long
 
  ' Create the session
  cryptCreateSession cryptSession, cryptUser, %CRYPT_SESSION_SSL 
 
  ' Add the server name and activate the session
  cryptSetAttributeString cryptSession, %CRYPT_SESSINFO_SERVER_NAME, serverName, Len( serverName )
 
  cryptSetAttribute cryptSession, %CRYPT_SESSINFO_ACTIVE, 1
 
       
  Activating a session results in cryptlib performing a lot of work in the background.
  For example when activating the SSL/TLS session shown above cryptlib will connect
  to the remote host, read the server’s certificate, generate a secret data value to
  exchange with the server using the key contained in the certificate, create the
  appropriate encryption contexts and load keys based on the secret data value into
  them, negotiate general session parameters, and complete negotiating the encrypted
  link with the server.
 
  Obtaining Session Status Information
  When a session is established a lot of state information is exchanged between the
  client and server and status information is generated by both sides. After the session
  has been activated you can query the session object for information such as the
  session status,
 
 
  Exchanging Data
  Once a general-purpose secure communications session has been established, you can
  exchange data with the remote client or server over the encrypted, authenticated link
  that it provides. This works exactly like pushing and popping data to and from an
  envelope, except that the session is effectively a bottomless envelope that can accept
  or return (depending on the remote system) an endless stream of data.

    
  When you close a session, cryptlib will immediately shut down the session as is,
  without flushing data in internal session buffers.