一、加密算法
加密算法运行于应用层，分为对称和非对称两类。
1.对称加密算法
对称算法就是通信双方协商一个共同的**，然后各方将需要传输的数据通过共同的**进行加密，然后传输，当收到经过加密的数据后，再通过共同**进行解密，这样就完成了加密通信。其缺点是每一对通信双方均需协商一个共同**，因此当通信双方的数量巨大时，将产生大量的共同**，难以管理，而且无法辨别无法发送者和接受者的身份，同时由于对称加密算法是基于共同保守秘密来实现的，采用对称加密技术的贸易双方必须保证采用的是相同的**，保证彼此**的交换是安全可靠的，同时还要设定防止**泄密和更改**的程序。
对称加密算法使用起来简单快捷，**较短，且破译困难，除了数据加密标准（DES），另一个对称**加密系统是国际数据加密算法（IDEA），它比DES的加密性好，而且对计算机功能要求也没有那么高。IDEA加密标准由PGP（Pretty Good Privacy）系统使用。
常见的对称加密算法有DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES
2.非对称加密算法（RSA算法）
2.1公钥和私钥
每一个需要通信的个体分别拥有一套用于RSA加密的参数，这套参数与具体传输的数据无关，这些参数包括6个数字，分别为
p 质数
q 质数
n n即p*q得到的一个大数的位数，即加密算法的位数，
目前可**768位的，1024位的安全，2048位的及其安全。
φ(n) φ(n) = (p-1)(q-1)，无需深入了解
e 随机选择一个整数e，条件是1< e < φ(n)，且e与φ(n) 互质，无需深入了解
d 计算e对于φ(n)的模反元素d，无需深入了解
其中，将n和e封装成公钥，n和d封装成私钥。
2.2 加密和解密
有了公钥和**，就能进行加密和解密了。
（1）加密要用公钥 (n,e)
假设鲍勃要向爱丽丝发送加密信息m，他就要用爱丽丝的公钥 (n,e) 对m进行加密。这里需要注意，m必须是整数（字符串可以取ascii值或unicode值），且m必须小于n。
所谓"加密"，就是算出下式的c：
me ≡ c (mod n)
爱丽丝的公钥是 (3233, 17)，鲍勃的m假设是65，那么可以算出下面的等式：
6517 ≡ 2790 (mod 3233)
于是，c等于2790，鲍勃就把2790发给了爱丽丝。
上面的过程说明，想要传输的数据m是参与了秘钥生成过程的，所以提供了数据的不可抵赖性。
（2）解密要用私钥(n,d)
爱丽丝拿到鲍勃发来的2790以后，就用自己的私钥(3233, 2753) 进行解密。可以证明，下面的等式一定成立：
cd ≡ m (mod n)
也就是说，c的d次方除以n的余数为m。现在，c等于2790，私钥是(3233, 2753)，那么，爱丽丝算出
27902753 ≡ 65 (mod 3233)
因此，爱丽丝知道了鲍勃加密前的原文就是65。
至此，"加密--解密"的整个过程全部完成。
我们可以看到，因为公钥是公开的，所以我们知道n，但是d掌握在Alice手中，如果不知道d，就没有办法从c求出m。
因此**该算法的过程为，已知公钥n,e和经过加密的数据c,求d。如果n可以被因数分解，d就可以算出，也就意味着私钥被**，以上推导过程略。因此RSA算法保证了通信安全。
（3）应用
公钥(n,e) 只能加密小于n的整数m，那么如果要加密大于n的整数，该怎么办？有两种解决方法：一种是把长信息分割成若干段短消息，每段分别加密；另一种是先选择一种"对称性加密算法"（比如DES），用这种算法的**加密信息，再用RSA公钥加密DES**。
非对称加密算法运行在HTTPS协议之上，该协议规定了通信所需要的端口号，以及提供了通信之间所需遵守的规范等的支持。相当于安全通信的载体，但不是核心，其核心是SSL协议。
2.3 总结
总的来说，其原理可以简单的总结为A有三个参数n1,e1,e2，将其中两个n1和e1公布出来，任何想要发送给自己数据的通信方利用n1和e1将数据m加密为c发功给A，A再解密。其基础建立在外界无法通过n1和e1得到e2，也就无法**c。
非对称：
A与B通信，则A首先要把自己的公钥传给B，此时，只能B向A传送数据。
然后B把自己的公钥传送给A，这时，A才能传送数据给B。
所以，如果A要想传送数据给B，则必须拥有B的公钥，
B想传送数据给A，同样也必须有A的公钥。
所以任何时候，想要传送数据的发起一方，必须拥有对方的公钥。
通信双方之间的连接不是紧密的，没有依存关系，所以是非对称的。即A有了B的公钥，只能保证可以向B发送数据，但是无法保证B也同时能够向A发送数据。
所以A与B之间如果建立了这种通信，那么如果想要获取他们之间的通信数据，则只有1个办法可行，那就是伪造身份，把自己伪造成他们中的一方，给对方自己的公钥，骗取对方发送数据给自己。
为了防止此类漏洞，出现了数字认证技术。此时网络传输安全问题就变成了验证通信双方的公钥是否可靠地问题了。
二、数字认证以及安全通信原理
2.1 数字认证
数字证书就好比我们生活中的身份证，现实中，身份证由*机关签发，而网络用户的身份凭证由数字证书颁发认证机构—CA签发，只有经过CA签发的证书在网络中才具备可认证性。
证书的签发过程实际上是对申请数字证书的公钥做数字签名，证书的验证过程实际上是对数字证书的公钥做验证签名，其中还包含证书有效期验证，通过CA数字证书，我们对网络上传输的数据进行加密/解密和签名/验证操作，确保数据机密性、完整性、抗否认性、认证性，保证交易实体身份的真实性，保证网络安全性。
我们先来看一个简单的证书机构签发的流程:
这里的认证机构如果是证书申请者本身，将获得自签名证书。
要获得数字证书，我们需要使用数字证书管理工具：KeyTool和OpenSSL构建CSR(数字证书签发申请)，交由CA机构签发，形成最终的数字证书。
当客户端获得服务器下发的数字证书后，即可使用数字证书进行加密交互：
数字证书的应用环境是在https安全协议中，由于非对称加密算法所能传输的数据比较小，所以在https安全协议中只使用非对称加密算法交换构成主**的参数，然后得到通信双方共同的公共**，即主**。该主**用来完成双方的对称加密通信，以此来提高加密/解密效率。
我们对上层的算法有了总体的认识。下面简单介绍一下这些算法的运行环境。HTTPS协议用来实现该算法。
2.2 HTTPS协议详解
HTTPS协议可以理解为在HTTP协议运行之前，通过SSL以及其继承者TLS协议为HTTP协议建立一个安全的加密的通信环境。HTTPS协议为数字证书提供了最佳的应用环境，HTTPS协议一般在服务器中配置，如HTTP服务器APACHE、TOMCAT等。SSL(secure socket layer):作为网络通讯提供安全以及数据完整性的一种安全协议
TLS(Transport Layer Security):作为SSL协议的继承者，成为下一代网络安全性和数据完整性安全协议
2.2.1 SSL层介绍：
SSL/TLS协议分为两层：
记录协议:建议在可靠的传输协议之上，为高层协议提供数据封装、压缩、加密等基本功能的支持
握手协议:建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换构成对称加密算法公共**的参数等
经过了SSL/TLS握手协议交互后，数据交互双方确定了本次会话使用的对称加密算法以及**，就可以开始进行加密数据交互了，以下是握手协议服务器端和客户端构建加密交互的相关流程图：
协商算法建立在记录协议之上，也就是说，他们之间的通信已经经过了数据封装、压缩、加密等基本功能。
协商算法
上面步骤4中RNC，我个人怀疑是否应该是RNS，否则后面的生成主**时，客户端缺一个参数。
为后面生成对称加密算法的主**准备条件。
1、 随机数为后续构建**准备
2、 其他信息包括服务器证书、甚至包含获取客户端证书的请求
服务器证书中包含了服务器的公钥，想要获取客户端证书，即想要获取客户端公钥，想要向客户端发送数据。
下一步就是验证服务器端的证书是否可靠了：
验证算法
如果服务器端回复客户端时带有其他信息，则进入数字证书验证阶段
客户端验证服务器端证书：
需要借助证书认证机构来验证服务器端的证书是否真实，也就是我们常说的第三方认证机构。
下一步客户端响应服务端的请求，把自己的证书发给服务端来验证。
服务器端验证客户端证书:
通过上述过程，非对称算法的通信连接建立了，双方可以采用该算法进行加密通信了，而且安全性极高。
采用该算法通信是为了为后面的通信产生**，也就是说为了保护后面的对称算法所产生的主秘钥。
产生主**(对称算法中的)
当服务器端和客户端经过上述流程后，就开始**构建交互了，服务器端和客户端最初需要主**为构建会话**做准备：
会话**
完成上述主**构建操作后，服务器端和客户端将建立会话**，完成握手协议：
会话秘钥我猜想是用主**做一个之前双方协商好的运算，比如说哈希运算，得到的相同的值。然后双方无需验证秘钥，只是在自己一方加密，传输，然后对方按照约定的规则自己计算解密，这样会提高通信的效率。这可能就是通信采用对称算法的原因。
加密交互
上述服务器端和客户端完成了握手协议以后就进入正式会话阶段，如果上述流程中有任何一端受到外界因素干扰发生异常，则重新进入协商算法阶段，下面流程表现进入会话阶段后，服务器端和客户端将使用会话**进行加密交互：
第7步可能是多余的。
所说的重新进入协商算法阶段，个人认为应该是重新协商会话秘钥的生成，而不是主**的生成算法的重新协商。
到此为止，数据便开始在加密算法的保护下在HTTPS协议上传输了。