在任何网络通讯中，我们最先考虑的应该是，与你通讯的对端，的的确确是真正的对端，而不是中间人。这也就是我们所说的AAA中的第一个A：认证。
1. 认证方式选择
说到认证，我们一般都会想到常用的认证方式，各自都有自己的使用场景，对比如下
| 认证方式 | 应用场景 |
| Identifier+PSK | IKEv1，IKEv2 |
| publice key / private key | SSH |
| username /passsword | SSH，AAA...... |
| PKI [Certificate] | SSL/TLS，IKEv2 |
| EAP | 802.1X，IKEv2 |
2. 常用认证方式
2.1 Identifier+PSK
该方式的原理是，在双方传输数据之前，提前配置好一模一样的密码，以identifier来区分不同的对端，identifier可以是对端ip地址，也可以是指定的字符串。
（1）当A要与B通信时，B会先产生一个随机数，然后查找与A对应的PSK密码，再用该密码加密随机数，发给A。
（2）A收到加密的随机数后，在本地查找与B对应的PSK密码，然后解密得到明文的随机数，然后给B
（3）B收到明文的随机数后，与自己生成的随机数比对即可，如果一样，说明双方的PSK密码相同，认证通过，否则失败。
同样地，当B要与A通信时，也是同样的认证方式。所以说 Identifier+PSK 这种认证方式，是单向的，如果要互相认证，那得重复一次。
2.2 publice key / private key
以SSH为例，我们来讲基于公钥/私钥的认证。当SSH客户端连接到服务器后，服务器会返回自己的公钥。如果是首次连接，客户端会弹出，让我们确认所连接的服务器身份真假。
如下图所示。
抓包如下
该方式需要我们人为确认服务器公钥是否正确，并且不能确认公钥提供方是真正的服务器还是中间人。
2.3 username / password
还以SSH为例来讲，上一节我们说到基于公钥/私钥的认证方式，是SSH客户端认证SSH服务器的方式。当SSH服务器认证客户端时，我们可以采用公钥/私钥的方式，也可以采用本节的用户名/密码的方式。
在SSH通信前，我们需要在服务器上配置账号和密码，当客户端登陆的时候，我们输入正确的账号密码即可。如下图所示。
2.4 PKI [Certificate]
2.4.1 证书接收方拿到证书时，会检验证书的哪些点？
（1）证书的是否过期
（2）证书的签名算法，客户端是否支持
（3）证书的common name 和 subject alternate name是否包含了，客户端请求时的域名/ip
（4）证书的issuer，在客户端的CTL里面是否可以找到
2.4.2 当证书的关键点都满足要求时，证书接收方怎么知道该证书真假呢？
在颁发证书的时候，证书颁发机构，也就是所谓的CA，会用自己签名算法中的哈希算法计算出证书的摘要值，再用私钥对该摘要值进行加密，最后形成了该证书的签名值，并附加在证书上。
根据PKI体系，证书接收方需要提前把证书持有方的证书颁发机构（CA）的证书，放到自己的证书信任列表（CTL）里面。当证书接收方拿到证书的时候，会用CTL里面证书持有方的CA证书里的公钥，解密附加在证书上的签名值，得到摘要值。
当证书接收方拿到证书的时候，同时会根据证书里面的签名算法中哈希算法对证书内容做哈希，计算出一个新的证书摘要值，然后用该新的摘要值去比对解密出来的摘要值，如果相同，就信任该证书，SSL/TLS握手继续；否则不信任，SSL/TLS握手失败，通知TCP关闭连接。
总结下，证书接收方拿到证书后，根据证书的签名值，以及提前内置在CTL里面的证书持有方CA证书，来判断证书的真假。
2.4.3 当服务器给客户端的是证书链时，客户端如何判断证书的真假？
以一个具体例子来讲，假设服务器给客户端的证书链是，Server Certificate <-- SubCA Certificate <-- RootCA Certificate。客户端只需要把RootCA Certificate放到CTL里面。
当客户端收到证书链时，由于RootCA证书已经内置在CTL里面，因此直接信任RootCA的证书。
SubCA证书的真假判断，利用SubCA证书的签名值，和RootCA证书来做依据，判断方式同上一节。
Server证书的真假判断，利用Server证书的签名值，和SubCA证书来做依据，判断方式同上一节。
2.4.4 如何解决中间人问题？
不过上面所说，都只能表明证书接收方信任证书发送方的证书而已，因为证书对所有人可见，如果中间人拿到发送方的证书，来冒充发送方，接收方怎么知道对端是真正的发送方还是中间人呢？
先说一般解决思路
（1）接收方收到证书以后，可以采用证书里面的公钥加密一段随机数，然后给到发送方/中间人，要求对端解密该公钥加密的随机数以后，明文发过来，与自己生成的比对即可。由于中间人，没有该公钥对应的私钥，无法解密该随机数，而是发送方据此就可以判断对端是真正发送方还是中间人。这是采用公私钥的方式来解决，SSH协议就是这样。
（2）还有一种方式就是采用PSK方式（例如：IKE协议），在认证之前，双方都提前拥有一个相同的PSK密钥，认证时，接收方要求用PSK密钥加密一段随机数，给发送方/中间人，要求对端解密该随机数，然后明文发过来，与自己生成的比对即可。由于中间人没有该PSK密钥，无法解密该随机数，而是发送方据此就可以判断对端是真正发送方还是中间人。
再看SSL/TLS的解决方法
其实SSL/TLS协议借鉴了上面两种思路来解决这个问题，我们知道在 SSL/TLS握手最后阶段有两个报文，Client Encrypted Handshake Message和Server Encrypted Handshake Message。
Encrypted Handshake Message的形成：Data in SSL/TLS Handshake ---> hash --> prf ---> encrypt with session key
session key的形成： parameters encrypted with Public Key ---> Key Exchange Algorithm
中间人没有与公钥对应的私钥，就无法解密parameters encrypted with Public Key ，从而无法拿到session key，没有session key，也就无法解密Encrypted Handshake Message，进而匹配不上Data in SSL/TLS Handshake ，因此验证方就知道被验证方的身份真假。
最后看IKEv2的解决办法
2.5 EAP
EAP是一个认证框架，包含了EAP-MD5、EAP-TLS、EAP-PEAP等认证方式，内容较多，我们另写一篇文档来讲。