什么是https者甲？？
wikipedia的解釋是：
超文本傳輸安全協(xié)議（英語：Hypertext Transfer Protocol Secure疲迂，縮寫：HTTPS煤蹭，常稱為HTTP over TLS膀篮，HTTP over SSL或HTTP Secure）是一種通過計算機網(wǎng)絡(luò)進行安全通信的傳輸協(xié)議。HTTPS經(jīng)由HTTP進行通信晃洒，但利用SSL/TLS來加密數(shù)據(jù)包垒玲。HTTPS開發(fā)的主要目的，是提供對網(wǎng)站服務器的身份認證岖免，保護交換數(shù)據(jù)的隱私與完整性
我們再來看看網(wǎng)絡(luò)安全的幾個基本問題岳颇。可以粗略的分成四個相互交織的領(lǐng)域：
保密
它的任務是確保信息不會被未經(jīng)授權(quán)的用戶訪問
認證
當你在展示敏感信息或者進入電子商務交易之前你必須要確定自己在和誰通話
不可否認
契約的任何一方不能否認自己曾經(jīng)簽過名的特性
完整性控制
用來確定你收到的信息是真實的而不是被惡意攻擊者在傳輸圖中篡改過的偽造信息
所以颅湘，理論上說將這四個問題解決就可以形成一個網(wǎng)絡(luò)安全的實現(xiàn)话侧。而https是一個典型的網(wǎng)絡(luò)安全問題解決方案，前面定義中涉及到的SSL/TLS加密闯参、身份認證瞻鹏、完整性等也都和這幾個問題呼應悲立。下面介紹基本的密碼學原理。
有哪些密碼學原理新博？薪夕？
保密——加密算法
密碼學眾所周知有兩種典型的加密技術(shù)：
對稱密鑰加密技術(shù)
發(fā)送端和接收端要共享相同的密鑰k才能進行通信，發(fā)送端接收端用共享的密鑰來加密報文和恢復報文赫悄，流行的對稱密鑰算法包括：DES原献、Triple-DES、AES埂淮，RC2和RC4
算法的細節(jié)我們不用考慮姑隅，不過很顯然，對稱加密的弱點就在于密鑰的管理倔撞。
對稱密鑰加密技術(shù)的缺點之一就是發(fā)送者和接收者在互相對話之前一定要有一個共享的保密密鑰讲仰，如果有N個節(jié)點每個節(jié)點都要和其他所有N-1個節(jié)點進行安全對話，總共大概會有N的平方個保密密鑰痪蝇，這將是一個管理噩夢鄙陡。
同時，加密安全性依賴于密鑰本身的安全性霹俺，共享密鑰的環(huán)節(jié)密鑰一旦泄露再健壯的算法也會被瞬間攻破柔吼。
公開密鑰加密技術(shù)
針對對稱密鑰的缺點，公開密鑰加密技術(shù)應運而生：
沒有對每對主機使用單獨的加密/解密密鑰丙唧，而是使用了兩個（非對稱）密鑰：一個用來對主機報文編碼愈魏，另一個用來對主機報文解碼。編碼密鑰是眾所周知的（這也是公開密鑰加密這個名字的由來）想际，但只有主機才知道私有的解密密鑰培漏，這樣每個人都能找到特定主機的公開密鑰編碼，而只有接收端才能對發(fā)送給它的報文進行解碼
即——<u>公鑰加密胡本，私鑰解密</u>牌柄。A和B每個主機有自己的公鑰，也有自己的私鑰侧甫，B想要給主機A發(fā)送報文珊佣，B就用主機A的公鑰進行加密，然后傳遞給A披粟，A再利用自己的私鑰進行解密就可以了咒锻。反之亦然。對于一個接受者來說守屉，任何人都可以用我分發(fā)出去的公鑰加密惑艇，但是加密之后只有我才能解密。這個方法解決了共享密鑰產(chǎn)生的密鑰安全性問題。
典型的非對稱加密算法是RSA滨巴。
同樣我們不需要知道算法的細節(jié)思灌，但是要了解的是，非對稱加密的缺點就是速度很慢恭取，如果數(shù)據(jù)都使用非對稱加密進行編碼傳輸效率會非常低泰偿。
上述的SSL/TLS本身并不是加密算法，他們是一組安全協(xié)議秽荤，構(gòu)成網(wǎng)絡(luò)協(xié)議棧當中的一個安全層甜奄。這個安全層提供一種機制讓收發(fā)雙方進行參數(shù)協(xié)商，認證窃款，保密通信课兄，數(shù)據(jù)的完整性保護等等，稍后會詳細說明晨继。
完整性——數(shù)據(jù)校驗和
加密提供了對明文保密的機制烟阐，不過它并不能保證發(fā)送內(nèi)容不被篡改。比如A向B發(fā)送加密數(shù)據(jù)紊扬，攻擊者C雖然不能解密A發(fā)送的密文信息蜒茄，但是可以自己隨意用B的公鑰加密一段密文或者在鏈路上竊取一段密文替換部分真實的A密文，從而破壞信息的正確性和完整性餐屎。那么如何做到被加密之后還不能被篡改呢檀葛？
對于保證數(shù)據(jù)完整性，密碼學給出的典型方案就是為明文計算一個校驗和或者叫摘要的信息（又叫指紋信息）腹缩，目前比較流行摘要有MD5屿聋，SHA1等等，它們能生成一個數(shù)據(jù)完整性的校驗和（MAC）藏鹊，和密文一并發(fā)送出去润讥。接收方拿到密文解密之后，用同樣的算法計算校驗和傳過來的校驗和比對盘寡，即可知道數(shù)據(jù)是否被篡改楚殿。加密內(nèi)容與校驗和是互校驗的，在加密算法安全的條件下竿痰，整個密文與校驗和是配套的脆粥，二者任何一處被修改都能被檢驗出來。
可是緊接著問題又來了影涉，如果報文并非期待的對象發(fā)出冠绢，而是攻擊者擅自發(fā)出的加密報文，整個報文都是假的呢常潮？
認證與不可否認——數(shù)字簽名
簽名的原理我們都理解，它用來證明文件是出自簽名者本人楷力，對于文件的接受人來說它具有認證的作用（確認文件的來源）喊式，對于文件的起草者有不可否認的作用（對于文件出自他不能抵賴）孵户。
那么在網(wǎng)絡(luò)環(huán)境中有沒有什么辦法起到“簽名”或者“按手印”這樣的作用呢。當然有岔留，也就是我們經(jīng)常聽到的一個詞叫“數(shù)字簽名”夏哭。
還記得剛剛講到的公開密鑰加密算法嗎，比如RSA献联，它的加密方式是公鑰加密竖配，私鑰解密。但是RSA算法也支持相反的一種工作方式里逆，即<u>私鑰加密进胯，公鑰解密</u>（私鑰加密的數(shù)據(jù)，只有對應的公鑰可以解開）原押。你可能困惑胁镐，這還加什么密啊，人人都能解密诸衔。的確是這樣盯漂，所以這種工作方式不在于向?qū)Ψ絺鬟f加密數(shù)據(jù)，而是為了說明數(shù)據(jù)的來源笨农，如果一段密文能夠用公鑰正確解密說明這個數(shù)據(jù)就是來自于私鑰屬主就缆，這恰恰是數(shù)字簽名的一種典型實現(xiàn)。
有了數(shù)字簽名谒亦，之前完整性校驗留下的問題是不是可以解決了竭宰？假設(shè)A需要發(fā)送一個報文，現(xiàn)在的報文結(jié)構(gòu)是密文+校驗和诊霹，如果我在此基礎(chǔ)上將校驗和用A的私鑰加密（也就是添加A的簽名）羞延，看看是什么效果：
對于攻擊者C來說，他拿到這樣一個報文脾还，首先他并不能解密密文（假設(shè)算法與密鑰安全）伴箩，其次他也不能篡改這個報文的任何一部分（加密密文，簽名的校驗和）鄙漏，因為這兩部分是互校驗的嗤谚，同時他也不能偽造整個報文，因為他不可能對校驗和有正確的簽名（沒有正確私鑰）怔蚌。由此可見加密+校驗和+數(shù)字簽名的方案很好的解決了破解巩步、篡改與偽造的問題。
所以數(shù)字簽名也可以簡單的理解成：<u>對校驗和進行私鑰加密</u>桦踊。
這個思路距離https實際的工作過程已經(jīng)很接近了椅野，不過之前我們一直有個問題沒考慮清楚。就是到底
采用哪一類加密算法？竟闪？
如果使用對稱加密算法离福，并且存儲通訊對象的密鑰，那么管理成本非常大炼蛤，也很危險妖爷。如果每次通信都交換密鑰，密鑰泄露的風險就變得更大理朋。但是反過來一旦安全交換了密鑰絮识，加密通信性能會比較好。同時對稱加密由于密鑰只關(guān)系到雙方嗽上，所以約定密鑰的人可以采用一個隨機值次舌，這樣安全交換密鑰之后，雙方可以不對自己的報文簽名也能驗證起到認證的作用炸裆。
如果使用非對稱加密算法垃它，在密鑰安全性方面相比對稱加密會好很多（依賴獲取的公鑰的安全性），但是每次通信獲取對方公鑰的成本會很高烹看，同時加密解密的性能會很差国拇。因為本身算法性能就差，而且非對稱加密的接受方每次必須通過簽名確認報文的屬主惯殊。于是發(fā)送方必須在發(fā)送報文時添加簽名酱吝，也就是說每個報文發(fā)送方要做兩次加密，接收方要做兩次解密土思。這種性能肯定是不能忍的务热。
所以對于這兩個矛盾又互補的方案來說，最好的辦法就是將它們結(jié)合起來使用己儒，因此崎岂，現(xiàn)實中https的方案：
是在兩個節(jié)點之間通過便捷的公開密鑰加密技術(shù)建立起安全通信，然后再用那條安全的通道產(chǎn)生發(fā)送臨時的隨機對稱密鑰闪湾，通過更快的對稱加密技術(shù)對其余的數(shù)據(jù)進行加密
更簡單一點理解冲甘，就是用<u>非對稱加密傳輸對稱加密的密鑰，然后用對稱加密通信</u>途样。
假設(shè)A發(fā)起與B的通信江醇，首先A獲取B的公鑰（先用非對稱加密），然后A告訴B何暇，“自己要用AES算法進行對稱加密陶夜，密鑰是xxx”，這個密鑰是一個隨機數(shù)裆站，然后這條報文用B的公鑰加密傳給B条辟，這條報文只有B能解密所以很安全黔夭，緊接著A和B就采用AES和約定的隨機密鑰加密報文，愉快的通信起來……
居然阻止不了“中間人攻擊”
這個方法看起來天衣無縫捂贿，首先用非對稱加密解決了對稱加密密鑰交換的問題纠修，對稱加密解決了性能問題，還不用每個報文都添加簽名認證……如果說還有什么不安全的地方厂僧，對，聰明的你一定發(fā)現(xiàn)了了牛，那就是獲取公鑰時的安全性颜屠。
還是剛才那個完全一樣的過程，只是第一步A獲取B公鑰時出現(xiàn)了問題鹰祸，假設(shè)A在四處打聽B的公鑰是什么甫窟，這時候攻擊者C跳出來說，我是B蛙婴，我的公鑰是kkk粗井，A很天真的相信了C的話，用kkk加密把密鑰給了C然后把跟B通信的內(nèi)容都發(fā)給了C街图，和C愉快的通信起來……
更過分的是C可能不一定會露出馬腳讓A發(fā)現(xiàn)他是偽裝者浇衬，他這邊與A建立通信之后反手又冒充A與真正的B建立通信，收到A的信息之后轉(zhuǎn)發(fā)給B餐济，B回傳的響應再轉(zhuǎn)發(fā)給A耘擂，他就這樣神不知鬼不覺的將AB之間的通信盡收眼底，時不時還能再添點油加點醋絮姆，前面研究半天的加密措施醉冤，全都被繞過了！
由此可見篙悯，公鑰的安全管理非常重要蚁阳，一旦拿到的是假公鑰那么連簡單的“中間人攻擊”都抵擋不了，前面利用那么多加密認證手段都前功盡棄了鸽照。
可是螺捐，非對稱加密以及后續(xù)全套加密全部工作就是建立在對所持公鑰的信任基礎(chǔ)上，我去哪拿安全的公鑰呢移宅，拿到公鑰的可信度又由誰來保證呢归粉？
數(shù)字證書——由一個可信組織簽名擔保公鑰安全性
又是一個熟悉的名詞，“數(shù)字證書”：
數(shù)字證書中包含了由某個受信任組織擔保的用戶或公司的相關(guān)信息漏峰。數(shù)字證書中還包含一組信息糠悼，所有這些信息都是由一個官方的“證書頒發(fā)機構(gòu)”已數(shù)字方式簽發(fā)的。有一些常見的內(nèi)容
- 對象的名稱（這個證書所描述的實體浅乔，人倔喂、服務器铝条、組織等）
- 過期時間
- 證書發(fā)布者（由誰為證書擔保）
- <u>來自證書發(fā)布者的數(shù)字簽名</u>
- <u>對象的公開密鑰</u>
- 對象和所用的簽名算法的描述性信息
可以這么理解，<u>數(shù)字證書上面寫著你要通信的服務器的公鑰席噩，同時這個證書加上了一個權(quán)威擔保機構(gòu)的簽名</u>班缰，證明這個公鑰的真實性。
也就是說悼枢，A現(xiàn)在要和B服務器進行安全通信埠忘，不需要四處尋找B的公鑰了，B會給A發(fā)送一個證書過來馒索，其實就是一張名片莹妒，上面寫著我是誰誰誰，地址在哪绰上，公鑰是多少旨怠，上面還蓋著一個“世界超級值得信任評估委員會”的大印。
A肯定會懷疑“世界超級值得信任評估委員會”是個什么鬼蜈块？因為這個擔保機構(gòu)可信度不高鉴腻。由此可見，無論是人還是協(xié)議都得有一個信任的衡量標準百揭，什么“世界”爽哎，什么“大機構(gòu)”都是空話。
證書與根證書
對于服務器發(fā)過來的證書信峻，瀏覽器的信任標準倦青，就在機器的本地。每臺機器的操作系統(tǒng)當中都安裝了很多的“根證書”盹舞，這些是權(quán)威機構(gòu)給自己頒發(fā)的产镐，<u>不需要其他人擔保的證書</u>。它上面的內(nèi)容也是有信譽的大機構(gòu)（CA組織）的公鑰踢步。根證書只要安裝到機器當中癣亚，瀏覽器（客戶端）就無條件認為上面的公鑰是可信的，而這些公鑰的作用就是驗證服務器發(fā)送過來的證書的簽名获印。比如上述“世界超級值得信任評估委員會”的簽名述雾，如果我的機器上安裝有該機構(gòu)的根證書，那么我就認為這個簽名是可信任的兼丰，然后就可以建立后續(xù)的安全通信了玻孟。
很多時候我們收到的證書并不只有一個，而是一組鳍征，比如一個B公司的站點給我一個證書黍翎，上面是B公司的信息，簽名是一個C機構(gòu)的艳丛，也就是由C機構(gòu)擔保（記作：<B,C>）匣掸，而這組證書當中還有兩個證書<C,D>和<D,E>趟紊，校驗簽名的時候C，D公司的簽名我都不認識（本地沒有二者的根證書）碰酝，但是E的簽名我認識并認為可信霎匈，因為我安裝了E的根證書。所以這就形成了一個“擔保鏈”：E擔保D擔保C擔保B送爸，出于對E的信任最終也信任了B铛嘱，這組證書叫做“證書鏈”。沒有從根證書發(fā)布機構(gòu)而是從其授權(quán)機構(gòu)申請的證書碱璃，都需要通過“證書鏈”的方式發(fā)送給接收者弄痹。
至此，https當中的關(guān)鍵概念都幫助大家掃盲了一遍嵌器。下面再說https的工作過程應該就很好理解了。
HTTPS工作過程
https特殊的工作過程體現(xiàn)在SSL/TLS層上谐丢，它建立在HTTP應用層協(xié)議之下作為一個安全服務層爽航，因此對于HTTP本身完全是透明的。因為在處理HTTPS流量時需要額外的安全層操作（加解密乾忱、驗證簽名讥珍、校驗等），所以tcp連接選擇建立在服務器的443端口上窄瘟，與http的80端口作以區(qū)分衷佃。
SSL是安全套接層（Secure Sockets Layer），由網(wǎng)景公司于1994年提出蹄葱，隨后SSL3.0由IETF進行了標準化氏义，發(fā)布了TLS（Transport Layer Security），二者差異很小图云，以下用SSL代指安全層惯悠。
對于SSL來說兩部分協(xié)議比較重要，一部分是“SSL握手協(xié)議”竣况，一部分是“SSL記錄協(xié)議”克婶。
SSL握手協(xié)議：
Note：上述消息5中，發(fā)送的是一個隨機的384位預設(shè)主密鑰丹泉，而真正的通信對稱密鑰是雙方用主密鑰與上面的兩個隨機數(shù)推導出來的情萤。
經(jīng)過握手以后，雙方就可以進行安全通信了摹恨，通信過程需要經(jīng)過SSL記錄協(xié)議來完成：
SSL記錄協(xié)議：
總結(jié)
對于https來說筋岛，其實就是靈活地將密碼學當中的諸多原理“拼裝”形成的一個安全方案。報文加密可以解決保密問題睬塌，數(shù)據(jù)校驗和可以解決完整性問題泉蝌，數(shù)字簽名可以解決身份認證與不可否認問題歇万。
https握手過程 1.確認具體算法 2.服務端（用證書）發(fā)送自己的公鑰 3.客戶端用<u>服務端公鑰</u>加密<u>對稱算法密鑰</u>發(fā)送給服務端 4.二者用對稱密鑰通信
其中，非對稱加密只在握手過程中只進行了一次勋陪，其余所有傳輸都用對稱加密贪磺。這個方案兼顧防止對稱密鑰泄露，同時避免了非對稱加密中認證和算法本身的額外性能開銷诅愚。
證書相當于告知一個公鑰寒锚，但是帶著一個ca組織的簽名，如果客戶端機器上安裝了對應組織的根證書违孝，那么這個證書上所有信息（最重要）相當于可信任刹前，防止“中間人攻擊”。
以上就是SSL的基本工作過程雌桑，本文省略了很多技術(shù)細節(jié)喇喉，強調(diào)安全傳輸?shù)恼w思路，希望能對大家理解https與網(wǎng)絡(luò)安全相關(guān)知識有一些幫助校坑。
