国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

我們現(xiàn)在經(jīng)常聽說誰誰誰密碼被盜了，誰誰誰信息又被劫持了。其中有一個(gè)原因：絕大部分網(wǎng)站用的是http這個(gè)明文協(xié)議。你以為很安全的在password框里填了隱藏的密碼，他卻一字一句明明白白的寫到了網(wǎng)絡(luò)上。于是乎好多網(wǎng)站開始從http遷移到https（至少登錄部分）。我也準(zhǔn)備做同樣的事情，因此抽時(shí)間和小伙伴tt一起研究了一下https。

剛開始看https的時(shí)候，各種頭大。國內(nèi)網(wǎng)上講相關(guān)的資料雖然一大堆，但是大部分是相互的抄，內(nèi)容多而亂，且沒有把事情講清楚。后來查閱了一些外文資料（包括rfc、wikipedia等），讀了JSSE的源代碼以后，基本把這個(gè)事情的來龍去脈看懂了大部分，但是涉及到很多很細(xì)節(jié)的東西還是覺得不是完全懂，如有疏漏和錯(cuò)誤，敬請(qǐng)大家指正和原諒 :-)

這篇文章的目標(biāo)：用盡量簡(jiǎn)單和有趣的語言，把這個(gè)復(fù)雜的東東講述清楚。所以，接下來我打算分成三部分來聊聊我理解的Https：

1、入門篇：主要用通俗的語言講講Https是什么東東，以及他大體的工作方式；

2、技術(shù)篇：結(jié)合抓包工具和源代碼，分析Https的通訊流程和細(xì)節(jié)；

3、理論篇：不是特別深入的聊聊一些跟Https相關(guān)的算法。

====入門篇的分割線====

What’s HTTPS？

簡(jiǎn)單的說，https就是給http帶了一個(gè)安全套，即使別人拿到了信息，也不知道這個(gè)里面裝的啥?？蛻舳耍ò╞rowser、手機(jī)app等）和服務(wù)器每次發(fā)http包的時(shí)候，都對(duì)這個(gè)包加個(gè)密，讓第三者看到的只是加密后的亂碼（我只想對(duì)你說：你猜你猜你猜猜猜），到對(duì)端以后再解密。

這個(gè)安全套，原來是叫SSL（Secure Sockets Layer），最先是Netscape弄出來的，后來哥們兒完蛋了，就慢慢變了名字，叫TLS（Transport Layer Security Protocol）。具體的區(qū)別可以去wikipedia搜索TLS，他們之間的升級(jí)細(xì)節(jié)講述的非常詳細(xì)（這一點(diǎn)百度百科真的差的有點(diǎn)遠(yuǎn)~）。

這個(gè)安全套跑在TCP的上層，在TCP連接完成后且HTTP啟動(dòng)前，協(xié)商一些跟加密相關(guān)的工作，完成協(xié)商之后，就可以對(duì)要發(fā)送的http包加密/解密了。

那他到底協(xié)商了些啥呢？其實(shí)就是保證安全的幾個(gè)問題：

1、服務(wù)器要證明自己是靠譜的、安全的，不然給一個(gè)假網(wǎng)站發(fā)加密的密文就跟裸奔沒啥區(qū)別

2、服務(wù)器和客戶端通訊需要的加密算法和加密密鑰

就跟當(dāng)年天地會(huì)和韋小寶通信一樣，先要亮出身份，證明自己，然后再拿出暗語的書信。

ComeOn! How TLS works?

第一步，服務(wù)器證明自己是靠譜的。

一個(gè)哥們兒XX說他是天地會(huì)的。如果你是韋小寶，你會(huì)怎么確認(rèn)他的身份呢？

其中有一種方案可能是這樣的：他會(huì)說S1是他師傅，如果你知道S1并和他確認(rèn)了，就ok了。如果不認(rèn)識(shí)，就繼續(xù)問S1的師傅S2……一直問道陳近南，只要陳近南確認(rèn)了，那就可以證明他了?？雌饋砗孟裨O(shè)計(jì)模式里面的責(zé)任鏈 XX -> S1 -> S2 -> … -> ROOT

服務(wù)器證明自己也是同樣的邏輯，服務(wù)器S0有一個(gè)證書，說我是誰誰誰，這個(gè)證書由上級(jí)簽發(fā)機(jī)構(gòu)S1核準(zhǔn)，如果你本地有這個(gè)S1的證書，那驗(yàn)證一下就可以了。如果沒有，就問S1的簽發(fā)機(jī)構(gòu)S2。直到根的簽發(fā)機(jī)構(gòu)。如果本地認(rèn)證找到了其中任何一級(jí)的證書，就認(rèn)為S0是靠譜的。否則就是不靠譜。S0 -> S1 -> S2 -> … -> Root CA

實(shí)際上非常像工商局發(fā)的營業(yè)執(zhí)照，你上面有我蓋的紅坨坨才是靠譜的。

上圖就是淘寶的認(rèn)證級(jí)聯(lián)關(guān)系。

這些靠譜的證書內(nèi)置在操作系統(tǒng)、jdk等地方（百度或者谷歌上搜索“https數(shù)字證書設(shè)置”相關(guān)內(nèi)容就可以看到）。

此圖就是我本機(jī)證書列表的一部分。

這個(gè)就是基本邏輯，說白了，就是找一個(gè)我們都公認(rèn)靠譜的人來證實(shí)你的靠譜。

第二步，協(xié)商加密算法+密鑰。

加密和摘要算法有很多，常見的比如RSA、AES、DES、MD5、SHA等等。

大家把他們這樣來分：

1、加密/解密算法：能加密同時(shí)能反解的，就是加解密算法。按照加解密的密鑰是否一樣，又分為對(duì)稱和非對(duì)稱算法。比如對(duì)稱加密算法：AES、DES；非對(duì)稱加密算法：RSA。

2、摘要算法：就是只用來做摘要、簽名、驗(yàn)證防止被別人篡改，基本不能反解（有可能可以通過碰撞暴力破解）。比如：MD5、SHA。

那服務(wù)器和客戶端接下來就協(xié)商一下，我們要用什么加密解密算法和密鑰防止別人看見，用什么摘要算法，防止別人篡改。

一般來講，對(duì)稱加密算法效率會(huì)比非對(duì)稱高，所以通常選擇對(duì)稱加密的AES較多。雙方通過某種方式協(xié)商出一個(gè)密鑰，后面就通過這個(gè)密鑰和加密算法進(jìn)行加解密。

客戶端發(fā)送一個(gè)：“地振高岡，一派溪山千古秀”

服務(wù)端回復(fù)一個(gè)：“門朝大海，三河合水萬年流”

整個(gè)過程大體就是這樣，后面雙方就開始發(fā)HTTP的加密包，對(duì)方解包得到對(duì)應(yīng)的HTTP數(shù)據(jù)。

世界一下就清晰了，對(duì)嗎？

No No No 其實(shí)還是很復(fù)雜滴…… 如果要想了解詳細(xì)的技術(shù)內(nèi)容，就讓我?guī)е憷^續(xù)往下看（你敢不敢跟我來）

===技術(shù)篇的分割線===

工欲善其事，必先利其器

為了做詳細(xì)的分析，我做了幾個(gè)準(zhǔn)備工作：

1、裝了一個(gè)wireshark，用來抓取網(wǎng)絡(luò)包

2、寫了一個(gè)java程序，打開debug運(yùn)行（java -Djavax.net.debug=all TestHttps），用來看交互細(xì)節(jié)

import java.net.URL;

import java.net.URLConnection;

public class TestHttps

{

public static void main(String[] args) throws Exception

{

final URL url = new URL('https://www.taobao.com');

final URLConnection conn = url.openConnection();

conn.connect();

}

}

3、找到openjdk源代碼：http://grepcode.com/

通過前兩個(gè)工作可以看到網(wǎng)絡(luò)交互的過程和詳細(xì)的數(shù)據(jù)包，第三個(gè)可以用來分析整個(gè)流程的代碼。

（注：以下涉及到代碼的分析，都是基于JDK8進(jìn)行的，如果因?yàn)榘姹驹?，相關(guān)函數(shù)和代碼行數(shù)對(duì)接不上，請(qǐng)大家查找對(duì)應(yīng)版本的代碼）

好了，準(zhǔn)備工作做好了，我們開始吧！

抓個(gè)包，先看看門道

先給taobao同學(xué)發(fā)個(gè)請(qǐng)求吧：curl https://www.taobao.com，看到整個(gè)交互過程大體是這樣的（我把tcp三次握手，ACK包等無關(guān)的數(shù)據(jù)包都過濾掉了，只剩TLS相關(guān)的數(shù)據(jù)包）：

上圖有幾個(gè)交互數(shù)據(jù)都合并到一個(gè)TCP包進(jìn)行發(fā)送了，比如漂藍(lán)的那一行（No = 49）的TCP包實(shí)際上包含了三個(gè)TLS包（Certificate、Server Key Exchange、Server Hello Done），下面分析的時(shí)候，我就把這個(gè)包展開。

上面抓的包全部展開就是這樣的效果。怎么樣，是不是差不多也看了個(gè)大概？我來翻譯翻譯吧。

看起來是不是很簡(jiǎn)單呢？

這實(shí)際上就是文章一開始，我說的要解決的兩個(gè)大問題：

1、認(rèn)證server端的靠譜性

2、交換加密算法和密鑰

具體每個(gè)包里面都發(fā)了哪些數(shù)據(jù)？server端靠譜性是如何來證明的？加密算法和密鑰是怎么交換的？接下來讓我一一給你道來。

具體的交互流程和代碼的實(shí)現(xiàn)

我們就按命令逐個(gè)來分析一下。

C：Client Hello

可以看到發(fā)送了很多數(shù)據(jù)，但是最關(guān)鍵的幾個(gè)數(shù)據(jù)：

1、TLS的版本

2、隨機(jī)數(shù)：這個(gè)是用來生成最后加密密鑰的影響因子之一，包含兩部分：時(shí)間戳（4-Bytes）和隨機(jī)數(shù)（28-Bytes）

3、session-id：用來表明一次會(huì)話，第一次建立沒有。如果以前建立過，可以直接帶過去。

4、加密算法套裝列表：客戶端支持的加密-簽名算法的列表，讓服務(wù)器去選擇。

5、壓縮算法：似乎一般都不用

6、擴(kuò)展字段：比如密碼交換算法的參數(shù)、請(qǐng)求主機(jī)的名字等等

這一段的java實(shí)現(xiàn)，是在sun.security.ssl.HandshakeMessage.ClientHello里面：

S：Server Hello

當(dāng)服務(wù)器收到客戶端的問候以后，立即做出了響應(yīng)：

大體內(nèi)容和客戶端差不多，只是把加密算法的套裝列表換成了服務(wù)器選擇支持的具體算法。

通過這一步，客戶端和服務(wù)器就完成了加密和簽名算法的交換。這里的TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256拆分開看就是：TLS協(xié)議，用ECDH密鑰交換算法交換對(duì)稱加密密鑰相關(guān)的參數(shù)，用RSA算法做簽名，最后使用AES_128_CBC做內(nèi)容的對(duì)稱加密，SHA256做摘要。

具體實(shí)現(xiàn)在：sun.security.ssl.HandshakeMessage.ServerHello

S：Certificate

這一步很關(guān)鍵，是服務(wù)器給客戶端展示證書的時(shí)候。

證書是一個(gè)鏈，從最底層一直到最頂層，表示誰誰誰給我認(rèn)證的。翻譯過來就是文章一開始給大家看到的那個(gè)東東：

證書一般采用X.509標(biāo)準(zhǔn)，后面我會(huì)詳細(xì)來講述證書格式和如何級(jí)聯(lián)認(rèn)證。X509證書具體實(shí)現(xiàn)在：sun.security.x509.X509CertImpl

Certificate消息的實(shí)現(xiàn)代碼在：sun.security.ssl.HandshakeMessage.CertificateMsg 里面

S：Server Key Exchange

這個(gè)消息是用來發(fā)送密鑰交換算法相關(guān)參數(shù)和數(shù)據(jù)的。這里要提前提一下，就是根據(jù)密鑰交換算法的不同，傳遞的參數(shù)也是不同的。

常用的密鑰交換算法：RSA、DH（Diffie-Hellman）、ECDH（Elliptic curve Diffie–Hellman）

后面會(huì)詳細(xì)來講這幾個(gè)算法的某幾個(gè)，現(xiàn)在就不詳細(xì)走這個(gè)分支，只是知道他們可以交換密鑰，有參數(shù)要傳遞即可。

（這里不得不感嘆一句，老外對(duì)基礎(chǔ)科學(xué)的研究真的是太深入了，這些算法十分的巧妙。希望有一天中國人也能對(duì)基礎(chǔ)科學(xué)做出更多的貢獻(xiàn)~）

可以看到這里用到的是ECDH算法，交換了一些參數(shù)，對(duì)數(shù)據(jù)做了簽名，防止劫持者篡改。

在Java里，這個(gè)消息有多個(gè)實(shí)現(xiàn)，分別代表RSA、DH、ECDH算法，對(duì)應(yīng)的類分別是：

sun.security.ssl.HandshakeMessage.ServerKeyExchange

sun.security.ssl.HandshakeMessage.RSA_ServerKeyExchange

sun.security.ssl.HandshakeMessage.DH_ServerKeyExchange

sun.security.ssl.HandshakeMessage.ECDH_ServerKeyExchange

以下是ECDH的實(shí)現(xiàn)：

S：Server Hello Done

Server要表達(dá)的信息基本表達(dá)完了，把主持人話筒交給客戶端：

對(duì)應(yīng)的實(shí)現(xiàn)：sun.security.ssl.HandshakeMessage.ServerHelloDone

C：Client Key Exchange

這是客戶端對(duì)Server Key Exchange的回應(yīng)，用于交換密鑰需要的參數(shù)。和服務(wù)器一樣，不同的密鑰交換算法實(shí)現(xiàn)是不一樣的，因此需要的參數(shù)也是有差異的。

這里用的是ECDH交換算法。

Java的實(shí)現(xiàn)也對(duì)應(yīng)的多個(gè)，分別是：

sun.security.ssl.RSAClientKeyExchange

sun.security.ssl.DHClientKeyExchange

sun.security.ssl.ECDHClientKeyExchange

以下是ECDH的具體實(shí)現(xiàn)：

好了，經(jīng)過以上的步驟，Server-Client已經(jīng)將服務(wù)器認(rèn)證的相關(guān)工作做完了，密文函數(shù)&密鑰交換需要的參數(shù)也都相互傳遞了。剩下的，就是各自用一個(gè)叫做PRF（Pseudo-Random Function）的算法去生成加密密鑰，具體的這個(gè)函數(shù)是一個(gè)對(duì)多因子多次迭代摘要運(yùn)算等的實(shí)現(xiàn)，這里姑且就當(dāng)做是一個(gè)很簡(jiǎn)單的隨機(jī)運(yùn)算函數(shù)吧，比如：key = rand_c + rand_s + C。

到這一步，客戶端和服務(wù)器就完成了密鑰相關(guān)的交換。

有了這個(gè)密鑰，接下來，客戶端和服務(wù)器就開始切換交流語言了（用密文開始說悄悄話），他們會(huì)各自發(fā)一個(gè)命令，說明自己已經(jīng)準(zhǔn)備好，開始切換語言了。

C：Change Cipher Spec

客戶端切換成密文模式

這個(gè)在Java里的實(shí)現(xiàn)在：sun.security.ssl.Handshaker

C：Finished（Encrypted Handshake Message）

這個(gè)包表明握手已經(jīng)完成，并且對(duì)之前發(fā)過的數(shù)據(jù)進(jìn)行加密發(fā)送給對(duì)方做校驗(yàn)，防止被篡改。同時(shí)也驗(yàn)證一下，加密算法、密鑰工作是否正常。

具體代碼在：sun.security.ssl.HandshakeMessage.Finished

在收到這兩個(gè)消息以后，服務(wù)器也發(fā)出同樣的消息，即：

S：Change Cipher Spec

S：Finished（Encrypted Handshake Message）

噓~~~（此地長(zhǎng)出一口氣） 至此，整個(gè)身份驗(yàn)證、加密/解密算法&密鑰的交換都已經(jīng)結(jié)束，剩余的，就是進(jìn)行正常的HTTP請(qǐng)求以及對(duì)請(qǐng)求數(shù)據(jù)的加密/解密。

以上這些步驟，都是對(duì)于使用ECDH密鑰交換算法、沒有session、不要求驗(yàn)證客戶端有效性的情況。對(duì)于有session的、或者要求驗(yàn)證客戶端有效性、或者使用其他密鑰交換算法的，請(qǐng)求會(huì)有不一樣，具體的可以看看實(shí)現(xiàn)代碼，里面都非常詳細(xì)也容易閱讀，具體代碼在：

sun.security.ssl.ClientHandshaker

sun.security.ssl.ServerHandshaker

里面有一個(gè)processMessage函數(shù)，是用switch...case寫的相關(guān)的狀態(tài)機(jī)。

看看，為了做安全的HTTP請(qǐng)求，需要額外付出多少的代價(jià)，來來回回需要多出多少次數(shù)據(jù)交換。

好了，如果還想了解其他更多更詳細(xì)的東東，就繼續(xù)跟我往下走，否則，在這里就可以return了 ^o^

===有點(diǎn)難度的理論分割線===

接下來準(zhǔn)備聊聊關(guān)于x509證書&證書驗(yàn)證、加解密、簽名、密鑰交換、隨機(jī)的一些算法。由于我自己對(duì)這部分沒有專門的研究，只是借這次機(jī)會(huì)看了一些資料，所以了解的不是非常深入，可能只能涉及一些皮毛，大家多多諒解和指正。

1、關(guān)于X.509證書&證書驗(yàn)證

X.509就是一個(gè)數(shù)字證書的標(biāo)準(zhǔn)，就像工商營業(yè)執(zhí)照一樣，證明你這個(gè)網(wǎng)站是合法的。詳細(xì)的可以參見wikipedia和RFC：

https://en.wikipedia.org/wiki/X.509

http://www.ietf.org/rfc/rfc2459.txt

在TLS中使用到了這樣一個(gè)證書來進(jìn)行有效性的認(rèn)證。因?yàn)椴皇菍I(yè)研究這個(gè)的機(jī)構(gòu)，我們就不深入去研究這個(gè)標(biāo)準(zhǔn)，而是看看他的數(shù)據(jù)格式和如何進(jìn)行驗(yàn)證。

證書的模樣

我們先看看wireshark抓到的包長(zhǎng)什么樣：

再看看Java的API文檔給出的比較詳細(xì)的定義：

http://docs.oracle.com/javase/8/docs/api/java/security/cert/X509Certificate.html

可以看出來，整體分為證書和對(duì)證書的簽名兩大部分。

證書包含：版本、序號(hào)、證書的簽名算法、簽發(fā)者、主題（被簽發(fā)者）、有效期等的信息。

為了方便閱讀，我們直接用chrome來查看證書：

可以看到非常詳細(xì)的信息，包括：被簽發(fā)者的基本信息、簽發(fā)者的基本信息，加密信息和簽名。我們?nèi)绻约河胦penssl做證書的話，都會(huì)要求相關(guān)項(xiàng)的填寫。有興趣的同學(xué)可以自己做一個(gè)證書試試手 ^_^

證書的驗(yàn)證

當(dāng)TLS協(xié)議驗(yàn)證一個(gè)網(wǎng)站是否有效的時(shí)候，Server會(huì)給出一個(gè)X509的證書鏈?？蛻舳耸盏竭@個(gè)證書鏈以后，對(duì)證書鏈進(jìn)行驗(yàn)證，所做的工作如下：

1、用最底端（證書鏈第一個(gè)）的證書，去驗(yàn)證請(qǐng)求的主機(jī)和證書里的是否是一致

2、逐次驗(yàn)證證書鏈里每張證書的合法性，直到找到一張證書在系統(tǒng)中存在：這一步又包含每張證書是否在不信任名單里、檢查簽名算法、檢查時(shí)間是否過期、檢查證書的發(fā)布者和證書鏈的上一級(jí)是否匹配、證書鏈的簽名檢查

以上檢查中，大多是按字節(jié)對(duì)比，相對(duì)比較簡(jiǎn)單，相關(guān)代碼參見以下幾個(gè)函數(shù)的實(shí)現(xiàn)：

sun.security.ssl.X509TrustManagerImpl.checkTrusted

sun.security.validator.SimpleValidator.engineValidate

sun.security.x509.X509CertImpl.verify

sun.security.x509.X509CertImpl.checkValidity

不過，其中證書鏈的簽名檢查是一個(gè)非常有意思的算法，這個(gè)算法我著實(shí)研究了一陣兒，還寫了一個(gè)簡(jiǎn)單的程序去實(shí)驗(yàn)，在這里稍微詳細(xì)講述一下。

我們得到了一個(gè)證書鏈，將他擴(kuò)展開成為一個(gè)層級(jí)關(guān)系：

對(duì)于每一級(jí)的證書，都是由上一級(jí)用私鑰對(duì)證書的sha摘要值進(jìn)行簽名（Root一般由自己簽發(fā)），簽名一般使用RSA算法。驗(yàn)證的時(shí)候，用上一級(jí)的公鑰對(duì)簽名進(jìn)行解密，還原對(duì)應(yīng)的摘要值。如下圖：

這里先提前最最最簡(jiǎn)單的插入一下RSA算法。RSA是非對(duì)稱加密，有一個(gè)公鑰（模數(shù)和指數(shù)）和一個(gè)私鑰。M代表明文消息，C代表密文，n代表公鑰模數(shù)，e代表公鑰指數(shù)，d代表私鑰。

如果我們用公鑰對(duì)明文M加密，私鑰解密，則是為了傳遞信息，對(duì)消息進(jìn)行加密；

如果我們用私鑰對(duì)明文M加密，公鑰解密，則是為了保證消息是我簽發(fā)的，沒有偽造和篡改。

這里，我們介紹后一種（即防篡改和偽造）。

簽名加密：C = (M ^ d) mod n

簽名解密：M = (C ^ e) mod n

先請(qǐng)不要問我為什么，后面會(huì)單獨(dú)講，哈哈哈（是不是很賤）~

好，回歸正題，上一級(jí)認(rèn)證機(jī)構(gòu)用私鑰(d)對(duì)下一級(jí)的證書的SHA數(shù)字簽名(M) 進(jìn)行RSA加密得到密文(C)。而第三方只要用上一級(jí)的公鑰(e, n)對(duì)這個(gè)加密進(jìn)行還原，并能得到相關(guān)的SHA數(shù)字簽名(M)，就可以認(rèn)為是經(jīng)過上一級(jí)認(rèn)證過的（因?yàn)橹挥兴拍芎灥某鰜恚?/p>

Come on，我們來實(shí)踐一下吧：

下圖淘寶上一級(jí)證書的公鑰（這些機(jī)構(gòu)就賣證書就可以賺翻了）：n（圖中的256字節(jié)公共密鑰）和 e（圖中的指數(shù)）

我們寫一個(gè)程序來驗(yàn)證一下：

因?yàn)橐么髷?shù)計(jì)算，所以用到了Java的大數(shù)類（這是用的最直接暴力的算法，其實(shí)還可以有很多優(yōu)化，比如O(n) -> O(lgn)，先取模再乘等等）。

最后輸出的結(jié)果如下：

1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003031300d060960864801650304020105000420bedfc063c41b62e0438bc8c0fff669de1926b5accfb487bf3fa98b8ff216d650

其中1fff...ff00是PKCS #1 v1.5 標(biāo)準(zhǔn)的前導(dǎo)補(bǔ)位，詳見：http://tools.ietf.org/html/rfc2313#page-9

接下來 303130…0420 是SHA-256摘要算法的標(biāo)識(shí)，詳見：http://tools.ietf.org/html/rfc3447#page-43

剩余部分正好32Bytes，是整個(gè)證書的SHA-256摘要。

是真的嗎？確認(rèn)那個(gè)32Bytes就是SHA-256的摘要么？來吧，我們寫一個(gè)程序驗(yàn)證一下：

這個(gè)程序大致的意思，就是截獲X509證書的驗(yàn)證，輸出對(duì)應(yīng)的證書信息。并用SHA-256對(duì)整個(gè)證書做摘要。得到的信息輸出如下：

======================

cert-count:

3

subject:

CN=*.tmall.com, O='Alibaba (China) Technology Co., Ltd.', L=HangZhou, ST=ZheJiang, C=CN

cert-sign:

3ec0c71903a19be74dca101a01347ac1464c97e6e5be6d3c6677d599938a13b0db7faf2603660d4aec7056c53381b5d24c2bc0217eb78fb734874714025a0f99259c5b765c26cacff0b3c20adc9b57ea7ca63ae6a2c990837473f72c19b1d29ec575f7d7f34041a2eb744ded2dff4a2e2181979dc12f1e7511464d23d1a40b82a683df4a64d84599df0ac5999abb8946d36481cf3159b6f1e07155cf0e8125b17aba962f642e0817a896fd6c83e9e7a9aeaebfcc4adaae4df834cfeebbc95342a731f7252caa2a97796b148fd35a336476b6c23feef94d012dbfe310da3ea372043d1a396580efa7201f0f405401dff00ecd86e0dcd2f0d824b596175cb07b3d

sha-256:

bedfc063c41b62e0438bc8c0fff669de1926b5accfb487bf3fa98b8ff216d650

======================

這個(gè)證書簽名以及對(duì)證書做的SHA-256摘要，和我們之前所得到的結(jié)果一樣一樣的~~

好了，到此為止，X509證書的格式和驗(yàn)證基本上也講了一個(gè)大概了，真是非常不容易啊（為了寫文章，肚子已經(jīng)餓的咕咕叫了）~

2.關(guān)于RSA算法

仔細(xì)想想，RSA算法在哪些地方被用到了呢？

1、證書簽名的時(shí)候（上面剛剛做了驗(yàn)證，對(duì)吧）

2、密鑰交換

為了防止信息被截獲篡改，需要對(duì)密鑰交換的參數(shù)做簽名。

所以，RSA算法是一個(gè)非常關(guān)鍵的加解密算法。那我們就來簡(jiǎn)單聊聊吧~

（最近看RSA，越看越覺得這個(gè)算法很有意思~）

注：為了在文本上打印方便，以下采用 ^ 這個(gè)符號(hào)作為乘方的運(yùn)算符，即2^4代表2的4次方。

來看看他的定義吧，老復(fù)雜了！

1、選兩個(gè)超級(jí)大的素?cái)?shù)：p 和 q

2、把他們乘起來：n = p * q

3、然后把p-1和q-1也乘起來：m = (p - 1) * (q - 1)

4、再找一個(gè)和m互質(zhì)的數(shù)：e -> gcd(e, m) = 1

5、最后，找一個(gè)d，滿足：(e * d) mod m = 1

6、然后公鑰就是(n, e)的組合，私鑰就是(n, d)的組合

……

我的媽，這么復(fù)雜，人都要瘋了，是不是？

為什么要搞這么復(fù)雜呢？

其實(shí)用到了幾個(gè)原理或者定理或者…… 他們分別是：

1、大數(shù)分解難題

2、費(fèi)馬小定理

3、中國剩余定理

4、擴(kuò)展歐幾里德算法

是不是被嚇蒙了呢？哈哈哈，由于這一篇是講Https的，所以就不詳細(xì)講這幾個(gè)原理，簡(jiǎn)單表述一下（就算是簡(jiǎn)單，也要說很多，也要碼很多的字……）。

首先，RSA建立的一個(gè)基本原則就是大數(shù)分解，如果沒有這個(gè)原則，就扯淡了。

我們給兩個(gè)素?cái)?shù)，比如 5 和 11。我們能很容易求出他們的乘積：5 * 11 = 55

當(dāng)然，在這個(gè)規(guī)模下，我們也很容易將 55 分解成 5 * 11。

但是，如果這兩個(gè)素?cái)?shù)很大呢，比如10的幾百次方。我們還是很容易求出他們的乘積。不過，你再想分解他，就不容易咯~

其次，著名的費(fèi)馬同學(xué)，發(fā)明了很多很多定理，其中比較著名的就是費(fèi)馬大小定理，小定理是這么說的：對(duì)于一個(gè)素?cái)?shù)n和任意的正整數(shù)a，( a ^ ( n - 1 ) ) mod n = 1

我們來試試，比如 n = 5，a = 4， 那么 a ^ ( n - 1 ) = 4 ^ ( 5 - 1 ) = 256，256 mod 5 = 1

很神奇吧！網(wǎng)上可以搜一搜詳細(xì)的證明。

這個(gè)公式演化一下，就可以得到a的n次方和a分別對(duì)n取模，結(jié)果是一樣的：( a ^ n ) ≡ a (mod n)

比如上面的那個(gè)例子：( 4 ^ 5 ) mod 5 = 4 ; 4 mod 5 = 4

那就是說如果n是一個(gè)素?cái)?shù)，任意一個(gè)數(shù)的i次方模n，都會(huì)呈現(xiàn)n-1個(gè)數(shù)的循環(huán)周期（不一定是最短的周期），比如：

4的1，2，3，4，5，6……次方模5的余數(shù)：4 1 4 1 4 1……

如果n是兩個(gè)素?cái)?shù)p和q的乘積，那么這個(gè)周期會(huì)呈現(xiàn) (p -1) * (q - 1)這么長(zhǎng)。也就是說，a 和 a的(p - 1) * (q - 1) + 1次方模n，得到的結(jié)果是一樣的。特別的，如果a <>

哈哈哈，繞了那么大一個(gè)彎子，最后的意思就是說，我只要知道 ( a ^ ( (p - 1) * (q - 1) + 1) ) mod n的余數(shù)，實(shí)際上就是知道了a，對(duì)吧！

那我只要變個(gè)花樣兒就可以。 我先讓m = (p - 1) * (q - 1) ，然后找一個(gè)和m互質(zhì)的數(shù)e，再求出一個(gè)d，讓 e * d = k * m + 1。這樣，我給一個(gè)數(shù)字 T (其中T < n)，計(jì)算出="" c="(T" ^="" e)="" mod="" n，="" 我拿著c做一個(gè)(c="" ^="" d="" )="" mod="" n，于是乎，神奇的一幕發(fā)生了：(c="" ^="" d)="" mod="" n="(" (t="" ^="" e)="" ^="" d="" )="" mod="" n="(" t="" ^="" (e="" *="" d)="" )="" mod="" n="(" t="" ^="" (k="" *="" m="" +="" 1)="" )="" mod="" n="T" mod="" n，因?yàn)?"" t="">< n="">

舉個(gè)例子，我們讓p = 5, q = 7，推算出來 n = 5 * 7 = 35, m = (5 - 1) * (7 - 1) = 24

我們找一個(gè)e，比方是11，那么一定可以找到一個(gè)d = 35，e * d = 11 * 35 = 385,

( e * d ) mod m = 385 mod 24 = 1

我們選一個(gè)數(shù)字T = 18， 計(jì)算 C = (T ^ e) mod n = 2

然后 計(jì)算 (C ^ d) mod n = 18 = T

以上就是RSA的原理，是不是要清楚一點(diǎn)了呢？

現(xiàn)在還有一個(gè)問題沒有解答，就是我們是怎么找出d來的，實(shí)際上就是要解一個(gè)方程：

( e * x ) mod m = 1 等價(jià)于 e * x + m * y = 1，其中x就是d。

這個(gè)就是中國剩余定理里面講到的東東，具體實(shí)現(xiàn)的時(shí)候，用擴(kuò)展輾轉(zhuǎn)相除法（這就是擴(kuò)展歐拉算法）做個(gè)迭代就出來了。

補(bǔ)充一點(diǎn)，RSA涉及到指數(shù)運(yùn)算，效率會(huì)比較低。實(shí)際上有很多優(yōu)化的方法，比如O(n) -> O(lgn)，先取模再乘，降維到p和q等等，就不在這里細(xì)展開了。

3.最后簡(jiǎn)單聊一個(gè)密鑰交換的DH算法

我們?cè)谥疤岬?，TLS要做的事情就是兩個(gè)：身份校驗(yàn) & 加密算法和密鑰協(xié)商。

身份校驗(yàn)我們前面已經(jīng)比較詳細(xì)的講述過了。加密算法的協(xié)商我們之前也在流程中講述過。剩下關(guān)于密鑰交換和協(xié)商，我們之前輕描淡寫的聊了下。下面稍微詳細(xì)的講述一下。

在密鑰交換的過程中，會(huì)用到一個(gè)PRF的函數(shù)，是”Pseudo-Random Function”這個(gè)的簡(jiǎn)稱，中間計(jì)算過程比較復(fù)雜，有興趣的同學(xué)可以在網(wǎng)上搜索查閱（由于偷懶，我沒有詳細(xì)深入這個(gè)函數(shù) ^_^）。

整個(gè)密鑰的生成大體如下：

master_secret = PRF(pre_master_secret, 'master secret', ClientHello.random + ServerHello.random)

具體代碼可以參見：

抽象上來講，就是 server和client 根據(jù)Hello時(shí)的兩個(gè)隨機(jī)數(shù) 加上 客戶端產(chǎn)生的pre_master_secret來產(chǎn)生一個(gè)master_secret，最后由這個(gè)東東生成需要的MAC（Message Authentication Code）、key等等加密需要東東。

那其中就有一個(gè)關(guān)鍵問題，客戶端的pre_master_secret怎么樣告訴服務(wù)器的？

我們可以用之前講過的RSA算法，客戶端通過服務(wù)器公鑰將這個(gè)值加密后傳遞給服務(wù)器，服務(wù)器再去解密。也可以通過一個(gè)叫做DH（Diffie-Hellman）的算法。維基百科對(duì)這個(gè)算法講的十分詳細(xì)。

我就簡(jiǎn)單翻譯一下：

有兩個(gè)哥們兒，Alice和Bob，他們想交換數(shù)據(jù)，于是乎也不知道怎么就想出了一個(gè)牛逼的算法：

1、取模數(shù) p = 23，底數(shù) g = 5

2、然后Alice想了一個(gè)整數(shù)a = 6，發(fā)送給Bob一個(gè)數(shù)：A = (g ^ a) mod p = (5 ^ 6) % 23 = 8

3、同理，Bob想了一個(gè)整數(shù)b = 15，發(fā)送給Alice一個(gè)數(shù)：B = (g ^ b) mod p = (5 ^ 15) % 23 = 19

4、Alice拿著Bob給的B = 19，計(jì)算了一個(gè)數(shù)：s = (B ^ a) mod p = (19 ^ 6) % 23 = 2

5、Bob也用同樣的方法，算了一下 : s = (A ^ b) mod p = (8 ^ 15) % 23 = 2

就這樣，在不泄露a、b的情況下，他們兩都得到了一個(gè)一樣的數(shù)。就這樣，數(shù)據(jù)交換了。。。

其實(shí)理論基礎(chǔ)就是： A ^ b ≡ (g ^ a) ^ b ≡ g ^ (a * b) ≡ (g ^ b) ^ a ≡ B ^ a (mod p)

更詳細(xì)的說明，可以看維基百科的解釋。

后來又有一個(gè)改進(jìn)的算法ECDH，這里就不詳細(xì)講述了（偷懶了，以后有機(jī)會(huì)再補(bǔ)~）

====總結(jié)的分割線====

好了，斷斷續(xù)續(xù)的抽大家睡覺的時(shí)間，把這篇文章寫完了（總算沒有當(dāng)太監(jiān)）。個(gè)人覺得把HTTPS整個(gè)的流程、交互的過程做了一個(gè)大體的了解。有一部分做的深入些，還有很多算法看了一個(gè)一知半解，越是深入?yún)s發(fā)現(xiàn)不懂或者不了解的越多。剩余還有幾個(gè)點(diǎn)由于篇幅和時(shí)間的原因沒有講到，比如：如何訪篡改、如何防回放攻擊、如何做PRF、交互里面有些擴(kuò)展參數(shù)等，后面準(zhǔn)備再抽時(shí)間把這些補(bǔ)全。

由于之前主要是聚焦在常規(guī)算法和互聯(lián)網(wǎng)技術(shù)架構(gòu)方面，對(duì)信息相關(guān)的科學(xué)了解不是那么深入。后面準(zhǔn)備把信息論、加解密算法的相關(guān)東西系統(tǒng)性的看下，完了之后分享出來。有興趣的同學(xué)可以關(guān)注我的微信：simplemain

作為一個(gè)碼工，就想安安靜靜做做技術(shù)。春天來了，可以有更多的時(shí)間聽著優(yōu)美的輕音樂寫更多的東西了。下面這張照片是我2012年4月在山東濟(jì)南拍的春天，4年時(shí)間過去了，又把他翻出來，感受一下當(dāng)年的春意盎然。Hello, World！

附：部分參考資料

https://en.wikipedia.org/wiki/Transport_Layer_Security

http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html

http://www-brs.ub.ruhr-uni-bochum.de/netahtml/HSS/Diss/MeyerChristopher/diss.pdf

http://grepcode.com/snapshot/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/

http://drops.wooyun.org/tips/11232

http://tools.ietf.org/html/rfc3447#page-43

http://netsecurity.51cto.com/art/201505/476337_all.htm

x509:

http://download.oracle.com/technetwork/java/javase/6/docs/zh/api/java/security/cert/X509Certificate.html

RSA:

http://blog.csdn.net/starryheavens/article/details/8536238

https://en.wikipedia.org/wiki/RSA_%28cryptosystem%29

Diffie-Hellman:

https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

http://my.oschina.net/u/1382972/blog/330456