1.基本概念

密码(cipher)

密码学中的密码（cipher）和我们日常生活中所说的密码不太一样，
计算机术语『密码 cipher』
是一种用于加密或者解密的算法，
而我们日常所使用的『密码 password』是一种口令，
它是用于认证用途的一组文本字符串，这里我们要讨论的是前者：cipher。

明文/密文

明文（plaintext）是加密之前的原始数据，
密文（ciphertext）是通过密码（cipher）运算后得到的结果成为密文

密钥(key)

密钥是一种参数，它是在使用密码（cipher）算法过程中输入的参数。
同一个明文在相同的密码算法和不同的密钥计算下会产生不同的密文。
很多知名的密码算法都是公开的，密钥才是决定密文是否安全的重要参数，通常密钥越长，破解的难度越大，比如一个8位的密钥最多有256种情况，使用穷举法，能非常轻易的破解，知名的DES算法使用56位的密钥，目前已经不是一种安全的加密算法了，主要还是因为56位的密钥太短，在数小时内就可以被破解。
密钥分为对称密钥与非对称密钥。

对称密钥/共享密钥加密

对称密钥（Symmetric-key algorithm）又称为共享密钥加密，对称密钥在加密和解密的过程中使用的密钥是相同的，
常见的对称加密算法有DES、3DES、AES、RC5、RC6。  
优点是，计算速度快，如果每个客户端与服务端单独维护一个密钥，那么服务端需要管理的密钥将是成千上万，这会给服务端带来噩梦。
缺点是，密钥需要在通讯的两端共享，让彼此知道密钥是什么对方才能正确解密，如果所有客户端都共享同一个密钥，那么这个密钥就像万能钥匙一样，可以凭借一个密钥破解所有人的密文了。

对称密码.png
非对称密钥

非对称密钥（public-key cryptography），又称为公开密钥加密，
服务端会生成一对密钥，一个私钥保存在服务端，仅自己知道，另一个是公钥，公钥可以自由发布供任何人使用。
客户端的明文通过公钥加密后的密文需要用私钥解密。
非对称密钥在加密和解密的过程的使用的密钥是不同的密钥，加密和解密是不对称的，所以称之为非对称加密。
与对称密钥加密相比，非对称加密无需在客户端和服务端之间共享密钥，只要私钥不发给任何用户，即使公钥在网上被截获，也无法被解密，仅有被窃取的公钥是没有任何用处的。
常见的非对称加密有RSA，非对称加解密的过程：

1.服务端生成配对的公钥和私钥
2.私钥保存在服务端，公钥发送给客户端
3.客户端使用公钥加密明文传输给服务端
4.服务端使用私钥解密密文得到明文

公钥密码.png
数字签名(非对称加密)

数据在浏览器和服务器之间传输时，有可能在传输过程中被冒充的盗贼把内容替换了，
那么如何保证数据是真实服务器发送的而不被调包呢，同时如何保证传输的数据没有被人篡改呢，
要解决这两个问题就必须用到数字签名，
数字签名就如同日常生活的中的签名一样，一旦在合同书上落下了你的大名，
从法律意义上就确定是你本人签的字儿，这是任何人都没法仿造的，因为这是你专有的手迹，任何人是造不出来的。

那么在计算机中的数字签名怎么回事呢？
数字签名就是用于验证传输的内容是不是真实服务器发送的数据，发送的数据有没有被篡改过，
它就干这两件事，是非对称加密的一种应用场景。
不过他是反过来用私钥来加密，通过与之配对的公钥来解密。

(1)发送报文时，发送方用一个哈希函数从报文文本中生成报文摘要,
然后用自己的私人密钥对这个摘要进行加密，
这个加密后的摘要将作为报文的数字签名和报文一起发送给接收方，
(2)接收方首先用与发送方一样的哈希函数从接收到的原始报文中计算出报文摘要，
接着再用发送方的公用密钥来对报文附加的数字签名进行解密，
如果这两个摘要相同、那么接收方就能确认该数字签名是发送方的。

生成签名和验证签名.png

数字证书（Certificate Authority）

数字证书简称CA，它由权威机构给某网站颁发的一种认可凭证，这个凭证是被大家（浏览器）所认可的。

全世界范围内可以发放安全证书的第三方机构就2-3个，而全世界有那么多的公司或网站需要申请证书。

#如何知道某个证书是否可信任呢？

其实安全证书有分根证书、子证书、子子证书，不同等级的信任范围。
通常根证书是由最上面的第三方机构颁发给自己的，
根证书下面的一级子证书通常是颁发给其下的代理公司的，
而如果你的网站是从代理公司申请的，那么你证书将会是一个二级子证书。

而在认证证书的时候， 操作系统或者程序会去检查该证书此前是否已经被信任过，
或者该证书的上级证书（父级、父父级等等）是否被信任过。
只要有一个等级的证书被信任过，则认为该证书是可信任的。

具体证书是否可信任是根据系统或者程序是否已安装并信任了该证书。
通常操作系统都会预装顶级证书机构的根证书，
所以只要你访问的网站证书是从这几个顶级第三方机构或其代理申请的，
那么就会被直接信任无需你去手动下载和安装。

#为什么需要用数字证书呢，难道有了数字签名还不够安全吗？
有这样一种情况，就是浏览器无法确定所有的真实服务器是不是真的是真实的，
举一个简单的例子：
A厂家给你们家安装锁，同时把钥匙也交给你，只要钥匙能打开锁，你就可以确定钥匙和锁是配对的，如果有人把钥匙换了或者把锁换了，你是打不开门的，你就知道肯定被窃取了，
但是如果有人把锁和钥匙替换成另一套表面看起来差不多的，但质量差很多的，虽然钥匙和锁配套，但是你却不能确定这是否真的是A厂家给你的，
那么这时候，你可以找质检部门来检验一下，这套锁是不是真的来自于A厂家，质检部门是权威机构，他说的话是可以被公众认可的。

同样的， 因为如果有人（张三）用自己的公钥把真实服务器发送给浏览器的公钥替换了，
于是张三用自己的私钥执行相同的步骤对文本Hash、数字签名，最后得到的结果都没什么问题，
但事实上浏览器看到的东西却不是真实服务器给的，而是被张三从里到外（公钥到私钥）换了一通。
那么如何保证你现在使用的公钥就是真实服务器发给你的呢？
我们就用数字证书来解决这个问题。
数字证书一般由数字证书认证机构（Certificate Authority）颁发，
证书里面包含了真实服务器的公钥和网站的一些其他信息，
数字证书机构用自己的私钥加密后发给浏览器，
浏览器使用数字证书机构的公钥解密后得到真实服务器的公钥。
这个过程是建立在被大家所认可的证书机构之上得到的公钥，所以这是一种安全的方式。

消息发送者利用认证机构向消息接收者发送密文.png
SSL/TLS

SSL（Secure Sockets Layer，安全套接层）是1994年由网景公司（Netscape）设计的一种协议，并在该公司的Web浏览器上进行了实现。
随后，很多Web浏览器都采用了这一协议，使其成为了事实上的行业标准。
SSL已经于1995年发布了3.0版本，但在2014年，SSL3.0协议被发现存在可能导致POODLE攻击的安全漏洞，因此SSL3.0已经不安全了。

TLS（Transport Layer Security ，传输层安全）是IETF在SSL3.0的基础上设计的协议。在1999年作为RFC2246发布的TLS1.0，实际上相当于SSL3.1。
2006年，TLS1.1以以RFC4346的形式发布，这个版本中增加了针对CBC攻击的策略并加入了AES对称加密算法。TLS1.2中新增了对GCM、CCM认证加密的支持，此外还新增了HMAC-SHA256，并删除了IDEA和DES，将伪随机函数（PRF）改为基于SHA-256来实现。

查看openssl证书

/etc/pki/CA 
      newcerts    存放CA签署(颁发)过的数字证书(证书备份目录)
      private         用于存放CA的私钥
      crl                 吊销的证书

/etc/pki/tls
      openssl.cnf     openssl的CA主配置文件
      private          证书密钥存放目录
      cert.pem       软链接到certs/ca-bundle.crt

查看TLS版本
centos/redhat:

yum info  gnutls

debian

dpkg   -l|grep gnutls

查看linux是否支持TLS1.0, TLS1.1及TLS1.2

openssl s_client -connect intl.jdair.net:443 -tls1

openssl s_client -connect intl.jdair.net:443 -tls1_1

openssl s_client -connect intl.jdair.net:443 -tls1_2

SSL/TLS的工作

我们想要实现通过本地的Web浏览器访问网络上的Web服务器，并进行安全通信。
举个例子来说就是，用户希望通过Web浏览器向xx银行发送信用卡号。在这里，我们有几个必须要解决的问题。
（1）用户的信用卡号和地址在发送到xx银行的过程中不能被窃听。
（2）用户的信用卡号和地址在发送到xx银行的过程中不能被篡改。
（3）确认通信对方的Web服务器是真正的xx银行。
在这里，
（1）是机密性问题，
（2）是完整性问题，
（3）则是认证的问题。
要确保机密性，可以使用对称密码。
由于对称密码的密钥不能被攻击者预测，因此我们使用伪随机数生成器来生成密钥。
若要将对称密码的密钥发送给通信对象，可以使用公钥密码或者Diffie-Hellman密钥交换。
要识别篡改，对数据进行认证，可以使用消息认证码。消息认证码是使用单向散列函数来实现的。
要对通信对象进行认证，可以使用对公钥加上数字签名所生成的证书。

SSL/TLS就是将对称密码、公钥密码、单向散列函数、
消息认证码、伪随机数生成器、数字签名等技术相结合来实现安全通信的。

TLS加密套件

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

TLS定义了几百个加密套件，可是在HTTP2面前基本都被否定了，列入了加密套件黑名单。
剩余的加密套件中，有20来个是被推荐的，还有二十来个没有被推荐

实现TLS1.2的话，下述加密套件中的一个是必要的:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256，
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384，
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

另外，还要为了兼容性实现一下HTTP2黑名单中的部分套件:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA，
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA，
TLS_RSA_WITH_AES_128_CBC_SHA，
TLS_RSA_WITH_AES_256_CBC_SHA，
TLS_RSA_WITH_3DES_EDE_CBC_SHA

不安全协议类型

FTP
Telnet
SSL1.0
SSL2.0
SSL3.0
TLS1.0

2.https(HyperText Transfer Protocol over Secure Socket Layer)

概念

是一种网络安全传输协议, HTTPS，也称作HTTP over TLS。
TLS的前身是SSL，
TLS 1.0通常被标示为SSL 3.1，
TLS 1.1为SSL 3.2，
TLS 1.2为SSL 3.3。
HTTPS是位于安全层之上的HTTP，这个安全层位于TCP之上

http & https.png

HTTP的几个缺点

HTTP协议的实现本身非常简单，不论是谁发过来的请求都会返回响应，因此不确认通信方，会存在以下隐患：
>> 无法确认请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是伪装的Web服务器。
>> 无法确认响应返回到的客户端是否是按真实意图接收响应的那个客户端，有可能是伪装的客户端。
>> 无法确定正在通信的对方是否具备访问权限，因为某些Web服务器上保存着重要的信息，只想发给特定用户通信的权限。
>> 无法判断请求是来自何方，出自何手。
>> 有人在通信的过程中抓取到了数据包, 可能导致数据被窃取。

即使是无意义的请求也会照单全收。无法阻止海量请求下的DoS攻击。

http传输中信息可能被篡改.png

https相关加密算法

HTTPS一般使用的加密与HASH算法如下：
>> 非对称加密算法：RSA，DSA/DSS
>> 对称加密算法：AES，RC4，3DES
>> HASH 算法：MD5，SHA1，SHA256

其中
>> 非对称加密算法用于在握手过程中加密生成的密码(即对称加密中的秘钥)，
>> 对称加密算法用于对真正传输的数据进行加密，
>> HASH 算法用于验证数据的完整性。

由于浏览器生成的密码是整个数据加密的关键，因此在传输的时候使用了非对称加密算法对其加密。
非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输。
而网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。

TLS握手过程中如果有任何错误，都会使加密连接断开，从而阻止了隐私信息的传输

https中非对称加密
https握手过程

图片.png

SSL 的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证，其主要过程如下：

1.客户端向服务器请求HTTPS连接:
客户端向服务器传送客户端 SSL 协议的版本号，加密算法的种类，
产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。

2.服务器确认并返回证书。
服务器向客户端传送 SSL 协议的版本号，加密算法的种类，
随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。

3.客户端验证服务器发来的证书。
客户端利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：
证书是否过期，
发行服务器证书的 CA 是否可靠(CA 认证机构颁发证书)，
发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，
服务器证书上的域名是否和服务器的实际域名相匹配。
如果合法性验证没有通过，通讯将断开;
如果合法性验证通过，将继续进行第4步。
// 关于验证 CA 证书 及可能的中间人攻击:
[
https://www.jianshu.com/p/76540830537f
]

4.信息验证通过，客户端生成随机密钥A，用公钥加密后发给服务器。
从第3步验证过的证书里面可以拿到服务器的公钥，客户端生成的随机密钥就使用这个公钥来加密.
加密之后，只有拥有该服务器(持有私钥)才能解密出来，保证安全。

5.服务器用私钥解密出随机密钥A，以后通信就用这个随机密钥A来对通信进行加密。
至此, 客户端和服务端的握手完成, 即可以开始进行加密传输了。


#须知:
这个握手过程并没有将验证客户端身份的逻辑加进去。
因为在大多数的情况下，HTTPS只是验证服务器的身份而已。
如果要验证客户端的身份，需要客户端拥有证书，在握手时发送证书，而这个证书是需要成本的。

https中对称加密--用于传输内容的加密

https中对称加密--用于传输内容的加密.png https交互过程.png

参考资源
https://www.jianshu.com/p/daa17f50fd93
https://www.itcodemonkey.com/article/5789.html
https://blog.csdn.net/xiaopang_yan/article/details/78709574
搜索关键词: https访问流程