说下ssl

openssl库的话，是把加密的信息放在了用户态，底层使用的tcp协议，在下面这个例子里，其实是可以如何获取到server端的证书的

http://fm4dd.com/openssl/sslconnect.shtm

这里不算是什么稀奇的事情，反正openssl和http这些协议一抓一大把。http的实现，go实现了，nginx也实现了，tls的协议，openssl实现了，其他的库和包也实现了。作为用户，我们就去使用就好了。那么今天的主要问题是。是使用这一台tls的协议，我们都需要提供什么信息呢？在上面的例子中，我们提供了一个域名，这个域名叫:https://www.hp.com，就这么一个输入的参数，然后呢，这个服务器端的cert就被咔嚓拿下来。可以发现在这个ssl的库的使用过程中，总有一些ctx这样的信息，这些信息都是session的语义。这个ctx就是session的语义了。

 在下面这个例子中，详细解释了一次数据的加解密的过程，ssl的作用不仅仅是对通信的数据进行加密，还要能验证客户端和服务器端的用户的身份。“SSL通信的第一个阶段是握手，握手发生在TCP建立连接之后，HTTP传输数据之前”。对于https，没有client端的certification这样一个步骤。

https://www.yanxurui.cc/posts/server/2017-09-13-secure-TCP-Data-using-TLS/

q在ssh握手的过程中，会索取server端的证书::: 1）该证书中的域名或者ip是否和预期的域名和ip匹配；2）该证书验证是否合法 3）对端是否是证书的持有者；为啥要验证这三三个问题。想想中间过程中出现的攻击：如果被中间人截获了，中间人拿着合法的server端的证书怎么办，毕竟这个证书是谁都可以拿的。其实啊，第三方拿着了也无所谓，但是想想这样一个场景，我们认为11.22.33.44是www.cnblogs .com的地址，但是11.22.33.44是台肉鸡，他提前知道了www.cnblogs.com的证书，结果用户请求发来的时候，各种验证都没有错误，于是所有的数据就都网11.22.33.44上发送了，这个时候其实11.22.33.44由于没有私钥，其实问题不大，但是会导致www.cnblogs.com的信息获取失败。https://github.com/honpey/codebox/blob/master/tls/echo_epoll_ssl.c

这里就是一个tls的例子了。所有的加解密都发生在用户态，SSL_CTX是最核心的结构体，这里有很多的结构体，包括公钥，私钥，包括自己签名的证书，这样数据从tcp上来之后，下去之前，都可以完成加密了～