OpenSSL学习（三）：基础【证书/加密算法/协议】

为什么80%的码农都做不了架构师？>>>   

一、证书

证书就是数字化的文件，里面有一个实体(网站，个人等)的公共密钥和其他的属性，如名称等。该公共密钥只属于某一个特定的实体，它的作用是防止一个实体假装成另外一个实体。 

证书用来保证不对称加密算法的合理性，只是保证双发的合法身份。

那么，如果证书是假的怎么办？或者证书被修改过了怎么办？慢慢看下来吧。 


证书最简单的形式就是只包含有证书拥有者的名字和公用密钥。当然现在用的证书没这么简单，里面至少还有证书过期的deadline,颁发证书的机构名称，证书系列号，和一些其他可选的信息。最重要的是，它包含了证书颁发机构(certificationauthority简称CA)的签名信息。 

我们现在常用的证书是采用X.509结构的，这是一个国际标准证书结构。任何遵循该标准的应用程序都可以读，写X509结构的证书。 

通过检查证书里面的CA的名字，和CA的签名，就知道这个证书的确是由该CA签发的然后，你就可以简单证书里面的接收证书者的名字，然后提取公共密钥。这样做建立的基础是，你信任该CA,认为该CA没有颁发错误的证书。 

CA是第三方机构，被你信任，由它保证证书的确发给了应该得到该证书的人。CA自己有一个庞大的publickey数据库，用来颁发给不同的实体。 

这里有必要解释一下，CA也是一个实体，它也有自己的公共密钥和私有密钥，否则怎么做数字签名？它也有自己的证书，你可以去它的站点down它的证书得到它的公共密钥。 

一般CA的证书都内嵌在应用程序中间。不信你打开你的IE,在internet选项里面选中"内容",点击"证书",看看那个"中间证书发行机构"和"委托根目录发行机构",是不是有一大堆CA的名称？也有时CA的证书放在安全的数据库里面。 

当你接受到对方的证书的时候，你首先会去看该证书的CA,然后去查找自己的CA证书数据库，看看是否找的到，找不到就表示自己不信任该CA,那么就告吹本次连接。找到了的话就用该CA的证书里面的公用密钥去检查CA在证书上的签名。 

这里又有个连环的问题，我怎么知道那个CA的证书是属于那个CA的？人家不能造假吗？ 

解释一下吧。CA也是分级别的。最高级别的CA叫RootCAs,其他cheap一点的CA的证书由他们来颁发和签名。这样的话，最后的保证就是：我们信任RootCAs.那些有RootCAs签名过的证书的CA就可以来颁发证书给实体或者其他CA了。 

你不信任RootCAs?人民币由中国人民银行发行，运到各个大银行，再运到地方银行，你从地方银行取人民币的时候不信任发行它的中国人民银行吗？RootCAs都是很权威的机构，没有必要担心他们的信用。 

那RootCAs谁给签名?他们自己给自己签名,叫自签名. 

说了这么多，举个certificate的例子吧,对一些必要的item解释一下。 
CertificateExample 
Certificate: 
Data: 
Version:1(0x0) 
SerialNumber://系列号 
02:41:00:00:16 
SignatureAlgorithm:md2WithRSAEncryption//CA同志的数字签名的算法 
Issuer:C=US,O=RSADataSecurity,Inc.,OU=Commercial//CA自报家门 
Certification 
Authority 
Validity 
NotBefore:Nov418:58:341994GMT//证书的有效期 
NotAfter:Nov318:58:341999GMT 
Subject:C=US,O=RSADataSecurity,Inc.,OU=Commercial 
CertificationAuthority 
SubjectPublicKeyInfo: 
PublicKeyAlgorithm:rsaEncryption 
RSAPublicKey:(1000bit) 
Modulus(1000bit): 
00:a4:fb:81:62:7b:ce:10:27:dd:e8:f7:be:6c:6e: 
c6:70:99:db:b8:d5:05:03:69:28:82:9c:72:7f:96: 
3f:8e:ec:ac:29:92:3f:8a:14:f8:42:76:be:bd:5d: 
03:b9:90:d4:d0:bc:06:b2:51:33:5f:c4:c2:bf:b6: 
8b:8f:99:b6:62:22:60:dd:db:df:20:82:b4:ca:a2: 
2f:2d:50:ed:94:32:de:e0:55:8d:d4:68:e2:e0:4c: 
d2:cd:05:16:2e:95:66:5c:61:52:38:1e:51:a8:82: 
a1:c4:ef:25:e9:0a:e6:8b:2b:8e:31:66:d9:f8:d9: 
fd:bd:3b:69:d9:eb 
Exponent:65537(0x10001) 
SignatureAlgorithm:md2WithRSAEncryption 
76:b5:b6:10:fe:23:f7:f7:59:62:4b:b0:5f:9c:c1:68:bc:49: 
bb:b3:49:6f:21:47:5d:2b:9d:54:c4:00:28:3f:98:b9:f2:8a: 
83:9b:60:7f:eb:50:c7:ab:05:10:2d:3d:ed:38:02:c1:a5:48: 
d2:fe:65:a0:c0:bc:ea:a6:23:16:66:6c:1b:24:a9:f3:ec:79: 
35:18:4f:26:c8:e3:af:50:4a:c7:a7:31:6b:d0:7c:18:9d:50: 
bf:a9:26:fa:26:2b:46:9c:14:a9:bb:5b:30:98:42:28:b5:4b: 
53:bb:43:09:92:40:ba:a8:aa:5a:a4:c6:b6:8b:57:4d:c5 

其实这是我们看的懂的格式的证书内容，真正的证书都是加密过了的，如下： 

-----BEGINCERTIFICATE----- 

MIIDcTCCAtqgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBiDELMAkGA1UEBhMCQ0gx 

EjAQBgNVBAgTCWd1YW5nZG9uZzESMBAGA1UEBxMJZ3Vhbmd6aG91MREwDwYDVQQK 

Ewhhc2lhaW5mbzELMAkGA1UECxMCc3cxDjAMBgNVBAMTBWhlbnJ5MSEwHwYJKoZI 

hvcNAQkBFhJmb3JkZXNpZ25AMjFjbi5jb20wHhcNMDAwODMwMDc0MTU1WhcNMDEw 

ODMwMDc0MTU1WjCBiDELMAkGA1UEBhMCQ0gxEjAQBgNVBAgTCWd1YW5nZG9uZzES 

MBAGA1UEBxMJZ3Vhbmd6aG91MREwDwYDVQQKEwhhc2lhaW5mbzELMAkGA1UECxMC 

c3cxDjAMBgNVBAMTBWhlbnJ5MSEwHwYJKoZIhvcNAQkBFhJmb3JkZXNpZ25AMjFj 

bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMDYArTAhLIFacYZwP30 

Zu63mAkgpAjVHaIsIEJ6wySIZl2THEHjJ0kS3i8lyMqcl7dUFcAXlLYi2+rdktoG 

jBQMOtOHv1/cmo0vzuf38+NrAZSZT9ZweJfIlp8W9uyz8Dv5hekQgXFg/l3L+HSx 

wNvQalaOEw2nyf45/np/QhNpAgMBAAGjgegwgeUwHQYDVR0OBBYEFKBL7xGeHQSm 

ICH5wBrOiqNFiildMIG1BgNVHSMEga0wgaqAFKBL7xGeHQSmICH5wBrOiqNFiild 

oYGOpIGLMIGIMQswCQYDVQQGEwJDSDESMBAGA1UECBMJZ3Vhbmdkb25nMRIwEAYD 

VQQHEwlndWFuZ3pob3UxETAPBgNVBAoTCGFzaWFpbmZvMQswCQYDVQQLEwJzdzEO 

MAwGA1UEAxMFaGVucnkxITAfBgkqhkiG9w0BCQEWEmZvcmRlc2lnbkAyMWNuLmNv 

bYIBADAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAGQa9HK2mixM7ML7 

0jZr1QJUHrBoabX2AbDchb4Lt3qAgPOktTc3F+K7NgB3WSVbdqC9r3YpS23RexU1 

aFcHihDn73s+PfhVjpT8arC1RQDg9bDPvUUYphdQC0U+HF72/CvxGCTqpnWiqsgw 

xqeog0A8H3doDrffw8Zb7408+Iqf 

-----ENDCERTIFICATE----- 
证书都是有寿命的。就是上面的那个NotBefore和NotAfter之间的日子。过期的证书，如果没有特殊原因，都要摆在证书回收列(certificaterevocationlist)里面.证书回收列，英文缩写是CRL.比如一个证书的key已经被破了，或者证书拥有者没有权力再使用该证书，该证书就要考虑作废。CRL详细记录了所有作废的证书。 

CRL的缺省格式是PEM格式。当然也可以输出成我们可以读的文本格式。下面有个CRL的例子。 



-----BEGINX509CRL----- 

MIICjTCCAfowDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxIDAeBgNVBAoT 

F1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYDVQQLEyVTZWN1cmUgU2VydmVy 

IENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw05NTA1MDIwMjEyMjZaFw05NTA2MDEw 

MDAxNDlaMIIBaDAWAgUCQQAABBcNOTUwMjAxMTcyNDI2WjAWAgUCQQAACRcNOTUw 

MjEwMDIxNjM5WjAWAgUCQQAADxcNOTUwMjI0MDAxMjQ5WjAWAgUCQQAADBcNOTUw 

MjI1MDA0NjQ0WjAWAgUCQQAAGxcNOTUwMzEzMTg0MDQ5WjAWAgUCQQAAFhcNOTUw 

MzE1MTkxNjU0WjAWAgUCQQAAGhcNOTUwMzE1MTk0MDQxWjAWAgUCQQAAHxcNOTUw 

MzI0MTk0NDMzWjAWAgUCcgAABRcNOTUwMzI5MjAwNzExWjAWAgUCcgAAERcNOTUw 

MzMwMDIzNDI2WjAWAgUCQQAAIBcNOTUwNDA3MDExMzIxWjAWAgUCcgAAHhcNOTUw 

NDA4MDAwMjU5WjAWAgUCcgAAQRcNOTUwNDI4MTcxNzI0WjAWAgUCcgAAOBcNOTUw 

NDI4MTcyNzIxWjAWAgUCcgAATBcNOTUwNTAyMDIxMjI2WjANBgkqhkiG9w0BAQIF 

AAN+AHqOEJXSDejYy0UwxxrH/9+N2z5xu/if0J6qQmK92W0hW158wpJg+ovV3+wQ 

wvIEPRL2rocL0tKfAsVq1IawSJzSNgxG0lrcla3MrJBnZ4GaZDu4FutZh72MR3Gt 

JaAL3iTJHJD55kK2D/VoyY1djlsPuNh6AEgdVwFAyp0v 

-----ENDX509CRL----- 

下面是文本格式的CRL的例子。 

ThefollowingisanexampleofaCRLintextformat: 

issuer=/C=US/O=RSADataSecurity,Inc./OU=SecureServerCertification 

Authority 

lastUpdate=May202:12:261995GMT 

nextUpdate=Jun100:01:491995GMT 

revoked:serialNumber=027200004CrevocationDate=May202:12:261995GMT 

revoked:serialNumber=0272000038revocationDate=Apr2817:27:211995GMT 

revoked:serialNumber=0272000041revocationDate=Apr2817:17:241995GMT 

revoked:serialNumber=027200001ErevocationDate=Apr800:02:591995GMT 

revoked:serialNumber=0241000020revocationDate=Apr701:13:211995GMT 

revoked:serialNumber=0272000011revocationDate=Mar3002:34:261995GMT 

revoked:serialNumber=0272000005revocationDate=Mar2920:07:111995GMT 

revoked:serialNumber=024100001FrevocationDate=Mar2419:44:331995GMT 

revoked:serialNumber=024100001ArevocationDate=Mar1519:40:411995GMT 

revoked:serialNumber=0241000016revocationDate=Mar1519:16:541995GMT 

revoked:serialNumber=024100001BrevocationDate=Mar1318:40:491995GMT 

revoked:serialNumber=024100000CrevocationDate=Feb2500:46:441995GMT 

revoked:serialNumber=024100000FrevocationDate=Feb2400:12:491995GMT 

revoked:serialNumber=0241000009revocationDate=Feb1002:16:391995GMT 

revoked:serialNumber=0241000004revocationDate=Feb117:24:261995GMT 



总结一下X.509证书是个什么东东吧。它实际上是建立了公共密钥和某个实体之间联系的数字化的文件。它包含的内容有： 

版本信息,X.509也是有三个版本的。 

系列号 
证书接受者名称 
颁发者名称 
证书有效期 
公共密钥 
一大堆的可选的其他信息 
CA的数字签名 

证书由CA颁发，由CA决定该证书的有效期，由该CA签名。每个证书都有唯一的系列号。证书的系列号和证书颁发者来决定某证书的唯一身份。 

openssl有四个验证证书的模式。你还可以指定一个callback函数，在验证证书的时候会自动调用该callback函数。这样可以自己根据验证结果来决定应用程序的行为。具体的东西在以后的章节会详细介绍的。 

openssl的四个验证证书模式分别是： 

SSL_VERIFY_NONE:完全忽略验证证书的结果。当你觉得握手必须完成的话，就选用这个选项。其实真正有证书的人很少,尤其在中国。那么如果SSL运用于一些免费的服务，比如email的时候，我觉得server端最好采用这个模式。 

SSL_VERIFY_PEER:希望验证对方的证书。不用说这个是最一般的模式了.对client来说，如果设置了这样的模式，验证server的证书出了任何错误，SSL握手都告吹.对server来说,如果设置了这样的模式,client倒不一定要把自己的证书交出去。如果client没有交出证书，server自己决定下一步怎么做。 

SSL_VERIFY_FAIL_IF_NO_PEER_CERT:这是server使用的一种模式，在这种模式下，server会向client要证书。如果client不给，SSL握手告吹。 

SSL_VERIFY_CLIENT_ONCE：这是仅能使用在sslsessionrenegotiation阶段的一种方式。什么是SSLsessionrenegotiation?以后的章节再解释。我英文差点，觉得这个词组也很难翻译成相应的中文。以后的文章里，我觉得很难直接翻译的单词或词组，都会直接用英文写出来。如果不是用这个模式的话,那么在regegotiation的时候，client都要把自己的证书送给server,然后做一番分析。这个过程很消耗cpu时间的，而这个模式则不需要client在regotiation的时候重复送自己的证书了。

二、加密算法

很烦杂，看一下《密码学》吧，记录点常识。

最常见的对称加密是DES.DES3,RC4等，常用的不对称加密一般有RSA,DSA,DH等。我们一般使用RSA。

数字签名也是不对称加密算法的一个重要应用，理解它对于理解SSL很重要的。

还有一种我们需要知道的加密算法，其实我不觉得那是加密算法，应该叫哈希算法，英文是messagedigest,是用来把任何长度的一串明文以一定规则变成固定长度的一串字符串。它在SSL中的作用也很重要，以后会慢慢提及的。一般使用的是MD5,SHA. 

base64不是加密算法，但也是SSL经常使用的一种算法，它是编码方式，用来把asc码和二进制码转来转去的。 

三、协议 

SSL(SecureSocketLayer)是netscape公司提出的主要用于web的安全通信标准,分为2.0版和3.0版.TLS(TransportLayerSecurity)是IETF的TLS工作组在SSL3.0基础之上提出的安全通信标准,目前版本是1.0,即RFC2246.SSL/TLS提供的安全机制可以保证应用层数据在互联网络传输不被监听,伪造和窜改.

一般情况下的网络协议应用中，数据在机器中经过简单的由上到下的几次包装，就进入网络，如果这些包被截获的话，那么可以很容易的根据网络协议得到里面的数据.由网络监听工具可以很容易的做到这一点。 

SSL就是为了加密这些数据而产生的协议，可以这么理解，它是位与应用层和TCP/IP之间的一层，数据经过它流出的时候被加密，再往TCP/IP送，而数据从TCP/IP流入之后先进入它这一层被解密，同时它也能够验证网络连接俩端的身份。 

它的主要功能就是俩个： 
一：加密解密在网络中传输的数据包,同时保护这些数据不被修改,和伪造。 

二：验证网络对话中双方的身份 

SSL协议包含俩个子协议，一个是包协议，一个是握手协议。包协议是说明SSL的数据包应该如何封装的。握手协议则是说明通信双方如何协商共同决定使用什么算法以及算法使用的key。很明显包协议位于握手协议更下一层。我们暂时对包协议的内容没有兴趣。 

SSL握手过程说简单点就是：通信双方通过不对称加密算法来协商好一个对称加密算法以及使用的key,然后用这个算法加密以后所有的数据完成应用层协议的数据交换。 

握手一般都是由client发起的，SSL也不例外。 

1、client送给server它自己本身使用的ssl的version(ssl一共有三个version),加密算法的一些配置，和一些随机产生的数据，以及其他在SSL协议中需要用到的信息。 

2、server送给client它自己的SSL的version,加密算法的配置，随机产生的数据，还会用自己的私有密钥加密SERVER-HELLO信息。Server还同时把自己的证书文件给送过去。同时有个可选的项目，就是server可以要求需要客户的certificate。 

3、client就用server送过来的certificate来验证server的身份。如果server身份验证没通过，本次通信结束。通过证书验证之后，得到server的公共密钥，解开server送来的被其用私有密钥加密过的SERVER-HELLO信息，看看对头与否。如果不对，说明对方只有该server的公共密钥而没有私有密钥，必是假的。通信告吹。 

4、client使用到目前为止所有产生了的随机数据(sharedsecret),client产生本次握手中的premastersecret(这个步骤是有可能有server的参与的，由他们使用的加密算法决定),并且把这个用server的公共密钥加密，送回给server.如果server要求需要验证client,那么client也需要自己把自己的证书送过去，同时送一些自己签过名的数据过去。 

SSL协议有俩种技术来产生sharedsecret(真不好意思，又是一个很难意译的词组), 
一种是RSA,一种是EDH. 

RSA就是我们上一章说过的一种不对称加密算法。首先server把自己的RSA公共密钥送给client,client于是用这个key加密一个随机产生的值(这个随机产生的值就是sharedsecret)，再把结果送给server. 

EDH也是一种不对称加密算法，但它与RSA不同的是，它好象没有自己固定的公共密钥和私有密钥，都是在程序跑起来的时候产生的，用完就K掉。其他的步骤俩者就差不多了。 

RSA,DSA,DH三种不对称加密算法的区别也就在这里。RSA的密钥固定，后俩个需要一个参数来临时生成key.DH甚至要求双方使用同样的参数，这个参数要事先指定。如果SSL库没有load进这个参数，DH算法就没办法用。DSA没研究过。 

5、Server验证完client的身份之后，然后用自己的私有密钥解密得到premastersecret然后双方利用这个premastersecret来共同协商，得到mastersecret. 

6、双方用master一起产生真正的sessionkey,着就是他们在剩下的过程中的对称加密的key了。这个key还可以用来验证数据完整性。双方再交换结束信息。握手结束。 

接下来双方就可以用协商好的算法和key来用对称加密算法继续下面的过程了。 

很简单吧？其实要复杂一些的，我简化了很多来说。 

不过还是有个问题，喜欢捣蛋的人虽然看不懂他们在交流些什么，但篡改总可以吧？ 
记得我们在加密算法里面介绍过的哈希算法吗？就是为了对付这种捣蛋者的。在每次送信息的时候，附带把整条信息的哈希值也送过去，接收方收到信息的时候，也把收到的内容哈希一把，然后和对方送来的哈希值对比一下，看看是否正确。捣蛋者如果乱改通信内容，哈希出来的值是不同的，那么就很容易被发现了。 

但这样子，捣蛋者至少可以学舌。他可以把之前监听到的内容重复发给某一方，而这些内容肯定是正确的,无法验证出有问题的。哎，SSL是怎么对付这种人的我还没看出来。有篇文章说：多放点随机数在信息里可以对付，我也没去研究这句话是什么意思。

转载于:https://my.oschina.net/acmfly/blog/72214