换用CyaSSL库

最近需要把openssl换成cyassl。因此做了一些记录和学习。
函数对照
建立SSL环境的函数这俩个函数是对等的

CyaSSL： CyaSSL_CTX_new(CyaSSLv23_client_method());
OpenSSL：SSL_CTX_new(SSLv23_client_method());

原OPENSSL的解读

数据结构
SSL_CTX用于SSL握手前的环境准备，设置CA文件和目录、设置SSL握手中的证书文件和私钥、设置协议版本以及其他一些SSL握手时的选项。

BIO是I/O abstraction。openssl抽象IO(I/O abstraction，即BIO)是openssl对于io类型的抽象封装，包括：内存、文件、日志、标准输入输出、socket（TCP/UDP）、加/解密、摘要和ssl通道等。Openssl BIO通过回调函数为用户隐藏了底层实现细节，所有类型的bio的调用大体上是类似的。Bio中的数据能从一个BIO传送到另外一个BIO或者是应用程序。

函数解读
SSL_library_init()加载各种加密和HASH算法。
SSL_load_error_strings()是加载SSL错误信息。
OpenSSL_add_all_algorithms()是SSL初始化。
SSL_CTX_new是申请SSL会话环境。
BIO_new_ssl_connect是该函数创建一个包含SSL类型BIO的新BIO链，并在后面附加了一个连接类型的BIO。
BIO_get_ssl()是该函数返回SSL类型BIO的内部的SSL结构指针，得到该指针后，可以使用标志的SSL函数对它进行操作。
SSL_set_mode(ssl,SSL_MODE_AUTO_RETRY)是

In light of the recv() and recv_into() implementation change (issue3890), I think we should enable SSL_MODE_AUTO_RETRY for SSL sockets. It prevents blocking read() calls from getting SSL_ERROR_WANT_READ at all.
(previously, we would loop manually in recv() and recv_into(); letting
the C OpenSSL runtime do it for us is certainly more efficient)

Never bother the application with retries if the transport is
blocking. If a renegotiation take place during normal operation,
a SSL_read(3) or SSL_write(3) would return with -1 and indicate
the need to retry with SSL_ERROR_WANT_READ. In a non-blocking
environment applications must be prepared to handle incomplete
read/write operations. In a blocking environment, applications
are not always prepared to deal with read/write operations
returning without success report. The flag SSL_MODE_AUTO_RETRY
will cause read/write operations to only return after the
handshake and successful completion.

BIO_write 是SSL类型的BIO会使用SSL协议进行底层的I/O操作。如果此时SSL连接并没有建立，那么就会在调用第一个IO函数的时候先进行连接的建立。
BIO_should_retry 是 【BIO_do_handshake】 函数在相关的BIO上启动SSL握手过程并建立SSL连接。连接成功建立返回1，否则返回0或负值，如果连接BIO是非阻塞型的BIO，此时可以调用 BIO_should_retry 函数以决定释放需要重试。如果调用该函数的时候SSL连接已经建立了，那么该函数不会做任何事情。

自己的理解

建立ssl连接的过程
1 建立SSL环境。
2 socket连接。
3 设置证书的等级模式。
4 ssl和socket对接。
5 发送和接收数据。

HTTPS的理解

HTTP有三个缺点，报文无加密，无法验证身份，不确定报文的完整。
HTTP是先和SSL通信。再有SSL和TCP通信。

如图：

https协议分层.png

非对称密钥：公开密钥加密，私有密钥解密。

HTTPS是对称密钥和非对称密钥组合使用。
HTTPS的通行过程是：

SSL_建立的过程.png

BUG记录

1 BUG001

编译好执行文件之后。./output 出现这个错误。

 ./output 
./output: error while loading shared libraries: libwolfssl.so.12: cannot open shared object file: No such file or directory

原因一般有两个, 一个是操作系统里确实没有包含该共享库(lib.so.文件)或者共享库版本不对, 遇到这种情况那就去网上下载并安装上即可.

另外一个原因就是已经安装了该共享库, 但执行需要调用该共享库的程序的时候, 程序按照默认共享库路径找不到该共享库文件.
我用

 ls -l /usr/local/lib/ | grep wolf

查了操作系统有安装。则就是有可能找不到路径。
于是就执行这三个命令，需要sudo的权限下执行这个命令。

[root@node1 rshell]# cat /etc/ld.so.conf
include ld.so.conf.d/*.conf
/usr/local/lib
/usr/local/lib/python2.7/lib-dynload
/home/SecDR_F118IV/solib/system/
[root@node1 rshell]# 
[root@node1 rshell]# echo "/usr/local/lib" >> /etc/ld.so.conf
[root@node1 rshell]# 
[root@node1 rshell]# 
[root@node1 rshell]# ldconfig

ldconfig命令的用途, 主要是在默认搜寻目录(/lib和/usr/lib)以及动态库配置文件/etc/ld.so.conf内所列的目录下, 搜索出可共享的动态链接库(格式如lib.so), 进而创建出动态装入程序(ld.so)所需的连接和缓存文件. 缓存文件默认为/etc/ld.so.cache, 此文件保存已排好序的动态链接库名字列表.
如果共享库文件安装到了/usr/local/lib(很多开源的共享库都会安装到该目录下)或其它"非/lib或/usr/lib"目录下, 那么在执行ldconfig命令前, 还要把新共享库目录加入到共享库配置文件/etc/ld.so.conf中。就是上图的第一第二条命令。

3. BUG003

在用CyaSSL_write发送报文的时候出现了如下错误。

confirm failure (-188).

这个错误在官网上有写。

Note 2) CyaSSL takes a different approach to certificate verification than OpenSSL does. The default policy for the client is to verify the server, this means that if you don't load CAs to verify the server you'll get a connect error, no signer error to confirm failure (-188). If you want to mimic OpenSSL behavior of having SSL_connect succeed even if verifying the server fails and reducing security you can do this by calling:

SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0);

before calling SSL_new(); Though it's not recommended.

所以我在调用CyaSSL_new之前用了CyaSSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0); 此错误就解决了。

CyaSSL_CTX_set_verify（）-----Description:

This function sets the verification method for remote peers and also
allows a verify callback to be registered with the SSL context. The
verify callback will be called only when a verification failure has
occurred. If no verify callback is desired, the NULL pointer can be
used for verify_callback.

SSL_VERIFY_NONE
Client mode:
the client will not verify the certificate received
from the server and the handshake will continue as normal.
Server mode:
the server will not send a certificate request to the client. As such,
client verification will not be enabled.