The libssl module performs the following tasks
NOTE: Unless authorized in advance by the core-network group, ALL cryptographic operations must be performed through the APIs provided by this module. Direct use of thirdparty crypto module APIs (such as libopeay) WILL NOT be authorized, except for modules that emulate the corresponding APIs provided by this module.
Additionally, ALL use of external thirdparty libraries that replace libssl as the SSL implementation MUST be inspected and approved by the libssl module owners before being shipped, and after major changes.
The primary APIs for the libssl module are
The SSL protocol implementation is implemented as state machine that calls specific handling functions based on the current state and the received messages. This code performs almost all of the handshake negotiation
The representation of records are represented as classes which are able to encode and/or decode the actual binary representation of the the record
The SSL_RecordLayer class handles the actual decoding of SSL network packets, as well as the decryption and encryption of records.
All handling of encryption and digest algorithms and certificate decoding and storage, as well as key-exchange and protocolversion specific operations are performed by subclasses of interface baseclasses. This permits a reasonable flexibility when adding new methods or new protocol versions, especially when the new methods are contained in a library different from the current crypto library. It also makes it easier to change crypto libraries, if that is required.
The module is fairly large (in the top 10 of core-2). Unused functionality has been disabled.
It is possible that a complete rewrite could reduce footprint somewhat, but probably not much, as has been observed in the diffie_3 rewrite. One possible exception is (possibly) if the current flexibility in cipher handling, digest and certificate handling was removed, resulting in a library that cannot easily be extented, except through the crypto library API.
A contributing factor to the footprintsize is the preshipped root certificate database, which may exceed 50 KB.
The module uses almost exclusively allocated memory in its operation, most of these have a relatively short lifespan. The structures with the longest timespans are stored either in the SSL_Options manager, or individual ServerName structures. Both of these are destroyed either at exit or when they are no longer used.
Most of the protocol code uses the SSL modules internal error code system to register errors. This system will raise the MemoryManager class' OOM condition flag if there are any OOM conditions. In case of an OOM the protocol will take the step required to shut down operations of the connection that failed.
Some classes, in particular SSL_Options, and API functions are capable of LEAVing or OP_STATUS in case of OOM, in which case it is the caller's responsibility to catch and act on the error.
The caller are responsible for handling TRAPped LEAVEs and OP_STATUS error codes. In the case of the MemoryManager flag the responsibility falls on the code dedicated to handling this flag.
Most of the module consists of stateengines (protocol, loadable structures), which are driven either by network events, internal messages, or external input. Functions that are not part of this usually perform specific tasks.
The module uses little stack space, but may create various temporary vectors and dataprocessing objects, which may exceed 200 bytes.
The module uses a few global variables for the main SSL_Options object and factory objects for the main implementations for MD5, SHA, certificates and 3DES
There are a number of hardcoded tables, the most significant of which is the cipher suite list in sslinit1.cpp, which is several KB. These can be implemented as allocated arrays on some platforms
ServerName objects contain a cache for accepted certificate and secure sessions. Unless used by a connection no more than one object of these will exist for any given ServerName and port. The cached objects can be freed through the URL module's Delete Private Data API (sensitive data)
The allocated memory is freed by the connections when they are closed, the SSL_Options securityManager when it is destroyed by Terminate() and the ServerName objects when they are deleted upon destruction by the URL_Manager.
No attempts are made to detect that they are already in use. The actual functions in which they are used are leaf functions or calls only leaf functions.
It is not possible to tune the module's memory usage.
Selftests, but no checks on memory usage
Surf on secure sites that exercises various conditions (wrong servername, verification errors etc.)
The primary classes are state engines. The primary reason is that the actions are either triggered by outside events, or they may not get complete data in on specific call.
No improvements are planned