SciSslSocket has the following methods:Closes and releases the SSL socket by shutting down the SSL connection that the receiver has opened with a peer. It then calls SciSocket>>close on the no-longer secure socket. For detailed information, see Socket Communications Interface.Specifies the session to use for the current connection. A session is an OSSslSession object that provides an interface to an underlying SSL session object.After a TCP/IP connection has been established between a client and server, sslAccept allows the server to wait for and accept a client request for a secure connection. The success of this call depends on an already established communication channel between the client and server and the initialization of an SSL structure (see ***) that captures the state of the connection.If the underlying socket is blocking, then sslAccept will only return once the handshake has been finished or an error has occurred. If an error occurs, an instance of SciSslError is returned with the error information generated by the underlying OpenSSL code.If the underlying socket is non-blocking, which is usually the case by default, then sslAccept may also return when the handshake cannot be completed. In this case, a call to sslGetError: with the return value of sslAccept will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. The calling process then must repeat the call after taking appropriate action to satisfy the needs of sslAccept. If an error occurs, an instance of SciSslError is generated and returned to the caller.If the underlying socket is blocking, sslConnect will only return once the handshake has been completed or an error has occurred. If the underlying socket in non-blocking, sslConnect will also return when the handshake cannot be completed. This allows the calling process to take appropriate measures and repeat the call as needed.Answers the 'actually used' cipher of a connection established by the ssl handle as an instance of SciSslCipher.The sslInitialize method creates a new SSL structure required to hold the data for the SSL/TLS connection. The new structure inherits the settings of the underlying SciSslContext instance which specifies the connection method (i.e. TLS, TLSv1.1), options, verification settings and timeout settings.
Server - the server will not send a client certificate request to the client, so the client will not send a certificate.
Client - if anonymous ciphers are not in use (by default disabled), the server will send a certificate which will be checked.
The result of the certificate verification process can be checked after the TLS/SSL handshake using the sslVerifyCertificate method. The handshake will be continued regardless of the verification result.
Server - the server sends a client certificate request to the client. The certificate returned (if any) is checked. If the verification process fails, the TLS/SSL handshake is immediately terminated with an alert message containing the reason for the verification failure. The behavior can be controlled by or-ing the additional SSL_VERIFY_FAIL_IF_NO_PEER_CERT and SSL_VERIFY_CLIENT_ONCE flags.
Client - the server certificate is verified. If the verification process fails, the TLS/SSL handshake is immediately terminated with an alert message containing the reason for the verification failure. If no server certificate is sent, because an anonymous cipher is used, SSL_VERIFY_PEER is ignored.
Server - if the client did not return a certificate, the TLS/SSL handshake is immediately terminated with a handshake failure alert. This flag must be used together with SSL_VERIFY_PEER.
Client - ignored
Server - only request a client certificate on the initial TLS/SSL handshake. Do not ask for a client certificate again in case of a renegotiation. This flag must be used together with SSL_VERIFY_PEER.
Client - ignored
|
|