1、對(duì)稱加密的理解：通信雙方共用一個(gè)秘鑰

2、非對(duì)稱加密(RSA):

        1、私鑰 + 公鑰 = 秘鑰對(duì)

        2、私鑰加密的數(shù)據(jù)只能公鑰解開，反之亦然

        3、通信之前雙方會(huì)把公鑰分別發(fā)給對(duì)方，然后用公鑰加密數(shù)據(jù)，雙方用自己的私鑰來解密 

3、采用非對(duì)稱加密造成速度緩慢的解決辦法

        1、先生成一個(gè)對(duì)稱加密算法的秘鑰、用RSA的方式安全的發(fā)給對(duì)方

        2、隨后再用對(duì)稱加密的秘鑰來通信 

4、再說說上面的方式，上面的方式存在一個(gè)明顯的中間人問題

假設(shè)客戶端和服務(wù)器之間存在一個(gè)中間人，這個(gè)中間人只要把原本雙方通信互發(fā)的公鑰換成自己的公鑰，這樣中間人們就可以輕松解密通信雙方所發(fā)送的所有數(shù)據(jù)

5、證書的出現(xiàn)就是為了解決以上問題

證書包括個(gè)人的基本信息和公鑰

簡(jiǎn)單的來說就是找一個(gè)大家公認(rèn)的中介，來證明我就是我，你就是你的問題，防止中間人篡改：

但證書還是會(huì)有問題，比如證書在傳輸?shù)倪^程中被篡改了呢，所以又出現(xiàn)了數(shù)字簽名。

6、數(shù)字簽名

        1、簡(jiǎn)單的說就是把公鑰和個(gè)人信息用一個(gè)hash算法生成一個(gè)消息摘要 

        2、這個(gè)hash算法有個(gè)極好的特性，就是輸入數(shù)據(jù)只要發(fā)生一點(diǎn)變化，那形成的消息摘要就會(huì)有巨變，能有效防止別人篡改 

        3、但如果中間人直接替換掉所有的整個(gè)原始信息，那么依舊可以偽造消息 

        4、所以就出現(xiàn)了CA, 這時(shí)CA在用他的私鑰對(duì)消息摘要進(jìn)行加密，形成簽名，并把原始信息和數(shù)據(jù)簽名進(jìn)行合并，即所謂的’數(shù)字證書’

        5、這樣當(dāng)別人把他的證書發(fā)過來的時(shí)候，我們?cè)儆猛瑯拥膆ash算法生成消息摘要，然后用CA公鑰進(jìn)行數(shù)字簽名解密，得到CA創(chuàng)建的消息摘要兩者對(duì)比就可以知道中間有沒有被人篡改了

7、https具體同心過程:

借用網(wǎng)上的一張圖：

HTTPS.png

過程解釋如下:

1、客戶端首先會(huì)將自己支持的加密算法，打個(gè)包告訴服務(wù)器端。

2、服務(wù)器端從客戶端發(fā)來的加密算法中，選出一組加密算法和HASH算法（注，HASH也屬于加密），并將自己的身份信息以證書的形式發(fā)回給客戶端。而證書中包含了網(wǎng)站的地址，加密用的公鑰，以及證書的頒發(fā)機(jī)構(gòu)等；我們常見的加密算法一般是一些對(duì)稱的算法，如凱撒加密；對(duì)稱算法即加密用的密鑰和解密用的密鑰是一個(gè)。還有一種加密解密算法稱之為非對(duì)稱算法。這種算法加密用的密鑰（公鑰）和解密用的密鑰（私鑰）是兩個(gè)不同的密鑰；通過公鑰加密的內(nèi)容一定要使用私鑰才能夠解密。這里，服務(wù)器就將自己用來加密用的公鑰一同發(fā)還給客戶端，而私鑰則服務(wù)器保存著，用戶解密客戶端加密過后的內(nèi)容。

3、客戶端收到了服務(wù)器發(fā)來的數(shù)據(jù)包后，會(huì)做這么幾件事情：

 1）驗(yàn)證一下證書是否合法。一般來說，證書是用來標(biāo)示一個(gè)站點(diǎn)是否合法的標(biāo)志。如果說該證書由權(quán)威的第三方頒發(fā)和簽名的，則說明證書合法。    

 2）如果證書合法，或者客戶端接受和信任了不合法的證書，則客戶端就會(huì)隨機(jī)產(chǎn)生一串序列號(hào)，使用服務(wù)器發(fā)來的公鑰進(jìn)行加密。這時(shí)候，一條返回的消息就基本就緒。

 3）最后使用服務(wù)器挑選的HASH算法，將剛才的消息使用剛才的隨機(jī)數(shù)進(jìn)行加密，生成相應(yīng)的消息校驗(yàn)值，與剛才的消息一同發(fā)還給服務(wù)器。

4、服務(wù)器接受到客戶端發(fā)來的消息后，會(huì)做這么幾件事情：

  1）使用私鑰解密上面第2）中公鑰加密的消息，得到客戶端產(chǎn)生的隨機(jī)序列號(hào)。

  2）使用該隨機(jī)序列號(hào)，對(duì)該消息進(jìn)行加密，驗(yàn)證的到的校驗(yàn)值是否與客戶端發(fā)來的一致。如果一致則說明消息未被篡改，可以信任。

  3）最后，使用該隨機(jī)序列號(hào)，加上之前第2步中選擇的加密算法，加密一段握手消息，發(fā)還給客戶端。同時(shí)HASH值也帶上。

5、客戶端收到服務(wù)器端的消息后，接著做這么幾件事情：

  1）計(jì)算HASH值是否與發(fā)回的消息一致    

  2）檢查消息是否為握手消息

6、握手結(jié)束后，客戶端和服務(wù)器端使用握手階段產(chǎn)生的隨機(jī)數(shù)以及挑選出來的算法進(jìn)行對(duì)稱加解密的傳輸。

為什么不直接全程使用非對(duì)稱加密算法進(jìn)行數(shù)據(jù)傳輸？這個(gè)問題的答案是因?yàn)榉菍?duì)稱算法的效率對(duì)比起對(duì)稱算法來說，要低得多得多；因此往往只用在HTTPS的握手階段。

以下是我們一些經(jīng)常使用的加密算法，是不是有熟悉的味道？

非對(duì)稱加密算法：RSA, DSA/DSS

對(duì)稱加密算法： AES, 3DES

HASH算法：MD5, SHA1, SHA256