在HTTP協(xié)議中有可能存在信息竊聽或身份偽裝等安全問題针炉。使用HTTPS通信機制可以有效地防止這些問題。
一、HTTP的缺點
到現(xiàn)在為止，我們已了解到HTTP具有相當優(yōu)秀和方面的一面格遭，然而HTTP并非只有好的一面，事物皆具有兩面性留瞳，它也是有不足支出的拒迅。
HTTP主要有這些不足，舉例如下她倘。
? ? 1.通信使用明文（不加密）璧微，內容可能會被竊聽
? ? 2.不驗證通信方的身份，因此有可能遭遇偽裝
? ? 3.無法證明報文的完整性帝牡，所以有可能已遭篡改
這些問題不僅在HTTP上出現(xiàn)往毡，其他未加密的協(xié)議中也會存在這類問題。
除此以外靶溜，HTTP本身還有很多缺點。而且懒震，還有像某些特定的Web服務器和特定的Web瀏覽器在實際應用中存在的不足（也可以說成是脆弱性或安全漏洞）罩息，另外，用Java和PHP等編程語言開發(fā)的web應用也可能存在安全漏洞个扰。
? ? 1）通信使用明文可能會被竊聽
由于HTTP本身不具備加密的功能瓷炮，所以也無法做到對通信整體（使用HTTP協(xié)議通信的請求和響應的內容）進行加密。即HTTP報文使用明文（指未經(jīng)過加密的報文）方式發(fā)送递宅。
? ? 1.TCP/IP是可能被竊聽的網(wǎng)絡
如果要問為什么通信時不加密是一個缺點娘香，這是因為苍狰，按TCP/IP協(xié)議族的工作機制，通信內容在所有的通信線路上都有可能遭遇到窺視烘绽。
所謂互聯(lián)網(wǎng)淋昭，是由能連通道全世界的網(wǎng)絡組成的。無論世界哪個角落的服務器在和客戶通信時安接，在此通信線路上的某些網(wǎng)絡設備翔忽、光纜、計算機等都不可能時個人的私有物盏檐，所以不排除某個環(huán)節(jié)中會遭遇到惡意窺視行為歇式。
即使已經(jīng)過加密處理的通信，也會被窺視到通信內容胡野，這點和未加密的通信是相同的材失。只是說如果通信經(jīng)過加密，就有可能讓人無法破解報文信息的含義硫豆，但是加密處理后的報文信息本身還是會被看到龙巨。
竊聽相同段上的通信并非難事。只需要收集在互聯(lián)網(wǎng)上流動的數(shù)據(jù)包（幀）就行了够庙。對于手機來的數(shù)據(jù)包進行解析工作恭应，可交給那些抓包（Packet Capture）或嗅探器（Sniffer）工具.
下面的圖片示例就是被廣泛使用的抓包工具Wireshark.它可以獲取HTTP協(xié)議額請求和響應的內容，并對其進行解析耘眨。
像使用GET方法發(fā)送請求昼榛、響應返回了200OK，查看HTTP響應報文的全部內容等一系列的事情都可以做到剔难。
2.加密處理防止被竊聽
在目前大家正在研究的如何防止竊聽保護信息的幾種對策中胆屿，最為普及的就是加密技術。加密的對象可以有那么幾個偶宫。
1》.通信的加密
一種方式就是講通信加密非迹。HTTP協(xié)議中沒有加密機制，但可以通過和SSL（Secure Socket Layer 纯趋，安全套接層）或TLS（Transport Layer Security憎兽，安全層傳輸協(xié)議）的組合使用，加密HTTP的通信內容吵冒。
用SSL建立安全通信線路之后纯命，就可以在這條線路上進行HTTP通信了。與SSL組合使用的http被稱為HTTPS（HTTP Secure 痹栖， 超文本傳輸協(xié)議）或HTTP over SSL亿汞。
2.》內容的加密
還有一種將參與通信的內容本身加密的方式。由于HTTP協(xié)議中沒有加密機制揪阿，那么就對HTTP傳輸協(xié)議的內容本身加密疗我。即把HTTP報文里所含的內容進行加密處理咆畏。
在這種情況下，客戶端需要對HTTP報文進行加密處理后再發(fā)送請求吴裤。
誠然旧找，為了做到有效的內容加密，前提是要求客戶端和服務端同時具備加密和解密機制嚼摩。主要應用在web服務中钦讳。有一點必須引起注意，由于該方式不同于SSL或TLS將整個通信線路加密處理枕面，所以內容仍有被篡改的風險愿卒，
? ? 2）不驗證通信方的身份就可能遭遇偽裝
HTTP協(xié)議中的請求和響應不會對通信方進行確認。也就是說存在“服務器是否就是發(fā)送請求中URI真正指定的主機潮秘，返回的響應是否真的返回到實際提出請求的客戶端”等類似問題琼开。
? ? 1.任何人都可以發(fā)送請求
在HTTP協(xié)議通信時，由于不存在確認通信方的處理步驟枕荞，任何人都可以發(fā)起請求柜候。另外，服務器只要接收到請求躏精，不管對方是誰都會返回一個相應（但也僅限于發(fā)送端的IP地址和端口號沒有被web服務器設定限制訪問的前提下）渣刷。
HTTP協(xié)議的實現(xiàn)本身非常簡單，不論是誰發(fā)送過來的請求都會返回響應矗烛，因此不確定通信方辅柴，會存在一下各種隱患。
1》無法確定請求發(fā)送至目標的web服務器是否是按真實意圖返回響應的那臺服務器瞭吃。有可能是已經(jīng)偽裝的web服務器碌嘀。
2》無法確定響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端。有可能是已偽裝的客戶端歪架。
3》無法確認正在通信的對方是否具備訪問權限股冗。因為某些web服務器上保存這重要的信息，只想發(fā)送給特定用戶的通信權限和蚪。
4》無法判斷請求是來自何方止状，出自誰手。
5》即使是無意義的請求也會照單全收攒霹，無法阻止海量請求下的DOS攻擊（Denial of Service , 拒絕服務攻擊）导俘。
2）查明對手的證書
雖然使用HTTP協(xié)議無法確定通信方，但如果使用SSL則可以剔蹋。SSL不僅提供加密處理，而且還使用了一種被稱為證書的手段辅髓，可用以確定方泣崩。
證書是由值得信賴的第三方機構頒發(fā)少梁，用以證明服務器和客戶端是實際存在的。另外矫付，偽造證書從技術角度來說是異常困難的一件事凯沪。所以只要能夠確認通信方（服務器或客戶端）持有的證書，即可判斷通信方的真實意圖买优。
通過使用證書妨马，以證明通信方就是意料中的服務器。這對使用者個人來講杀赢，也減少了個人信息泄露的危險性烘跺。
另外，客戶端持有證書即可完成個人身份的確認脂崔，也可用于對web網(wǎng)站的認證環(huán)節(jié)滤淳。
3）無法證明報文完整性，可能已遭篡改
所謂完整性是指信息的準確度砌左。若無法證明其完整性脖咐，通常也就意味著無法判斷信息是否準確。
? ? 1》接收到的內容可能有誤
由于HTTP協(xié)議無法證明通信的報文完整性汇歹，因此屁擅，在請求或響應送出之后直到對方接收之前的這段時間內，即使請求或響應的內容遭到篡改产弹，也沒有辦法獲悉派歌。
換句話說，沒有任何辦法確認取视，發(fā)出去的請求/響應he接收到的請求/響應時前后相同的硝皂。
比如，從某個web網(wǎng)站上下載內容作谭，是無法確定客戶端下載的文件和服務器上存放的文件是否前后一致的稽物。文件內容在傳輸途中可能已經(jīng)被篡改為其他的內容。即使內容真的已改變折欠，作為接收方的客戶端也是察覺不到的贝或，
像這樣，請求或響應的傳輸途中锐秦，遭攻擊者攔截并篡改內容的攻擊稱為中間人攻擊（Man-in-the-Middleattack, MITM).
? ? 1》如何防止篡改
雖然有使用HTTP協(xié)議確保報文完整性的方法咪奖，但事實上并不便捷、可靠酱床。其中常用的是MD5和SHA-1等散列檢驗的方法羊赵，以及用來確認文件的數(shù)字簽名方法。
提供文件下載服務的web網(wǎng)站也是提供相應的已PGP（Pretty Good Privacy，完美隱私）創(chuàng)建的數(shù)字簽名及MD5算法生成的散列值昧捷。PGP是用來證明創(chuàng)建文件的數(shù)字簽名闲昭，MD5是由單向函數(shù)生成的散列值。不論使用哪一種方法靡挥，都需要操作客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件序矩。柳林愛情無法自動幫用戶檢查。
可惜的是跋破，用這些方法也依然無法百分百的保證確認結果正確簸淀。因為PGP和MD5本身被改寫的話，用戶是沒有辦法意識到的毒返。
為了有效防止這些弊端租幕，有必要使用HTTPS .SSL提供認證和加密處理及摘要功能，僅靠HTTP確保完整性是非常困難的饿悬，因此通過和其他協(xié)議組合使用來實現(xiàn)這個目標令蛉。
二、HTTP + 加密 + 認證 + 完整性保護 = HTTPS
? ? 1）HTTP加上加密處理和認證以及完整性保護后即是HTTPS
如果在HTTP協(xié)議通信過程中使用未經(jīng)加密的明文狡恬，比如在web頁面中輸入了信用卡號珠叔，如果這條通信線路遭到竊聽，那么信用卡號就暴露了弟劲。
另外祷安，對于HTTP說，服務器也好兔乞，客戶端也好汇鞭，都是沒有辦法確認通信方的。因為很有可能并不是和原本預想的通信方在實際通信庸追，并且還需要考慮到接收到報文在通信途中已經(jīng)遭到篡改這一可能性霍骄。
為了統(tǒng)一解決上述這些問題，需要在HTTP上在加入加密處理和認證等機制淡溯。我們把添加了加密機認證機制的http稱為HTTPS读整。
經(jīng)常會在web的登錄頁面和購物結算界面等使用HTTPS通信。使用HTTPS通信時咱娶，不在用http://米间，而是改用https://。另外膘侮，當瀏覽器訪問https通信有效的web網(wǎng)站時屈糊，瀏覽器的地址欄內會出現(xiàn)一個帶鎖的標記。對https的顯示方式會因瀏覽器的不同而有所改變琼了。
? ? 2）HTTPS是身披SSL外殼的HTTP
HTTPS并非是應用層的一種新協(xié)議逻锐。只是HTTP通信接口部分用SSL（Secure Socker LaYER）和TLS（Transport Layer Security）協(xié)議代替而已。
通常，HTTP直接和TCP通信谦去，當使用SSL時慷丽，則演變成先和SSL通信，再由SSL和TCP通信了鳄哭。簡言之，所謂HTTPS纲熏，其實就是身披SSL協(xié)議這層外殼的HTTP.
在采用SSL后妆丘，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能局劲。
SSL是獨立于HTTP的協(xié)議勺拣，所以不光是HTTP協(xié)議，其他運行在應用層的SMTP和Telnet 等下協(xié)議均可配合SSL協(xié)議使用鱼填∫┯校可以說SSL是當今世界上應用最為廣泛的網(wǎng)絡安全技術。
? ? 3)相互交換秘鑰的公開密鑰加密技術
在對SSL進行講解之前苹丸，我們先來了解一下加密方式愤惰。SSL采用一種叫做公開密鑰加密（Public-key-cryptography）的加密處理方式。
近代的加密方法中加密算法是公開的赘理，而密鑰卻四保密的宦言。通過這種方式得以保持加密方法的安全性。
加密和解密都會用到密鑰商模。沒有密鑰就無法對密碼解密奠旺，反過來說，任何人只要持有密鑰就能解密了施流。如果密鑰被攻擊者獲得响疚，那加密也就失去了意義。
? ? 1.共享密鑰加密的困境
共享和解密同用一個密鑰的方式稱為共享密鑰加密（Common Key Crypto system）,也被叫做對稱密鑰加密瞪醋。
以共享密鑰方式加密時必須將密鑰也發(fā)給對方忿晕。可究竟怎樣才能安全地轉手趟章？在互聯(lián)網(wǎng)上轉發(fā)密鑰時杏糙，如果通信被監(jiān)聽那么密鑰就可會落入攻擊者之手，同時也就失去了加密的意義蚓土。另外還得設法安全地保管接收到的密鑰宏侍。
2.使用兩把密鑰的公開密鑰加密
公開密鑰加密方式很好滴解決了共享密鑰加密的困難。
公開密鑰加密使用一對非對稱的密鑰蜀漆，一把叫做私有密鑰（private key ）,另一把叫做公開密鑰（public key）.顧名思義谅河，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發(fā)布，任何人都可以獲得绷耍。
使用公開密鑰加密方式吐限，發(fā)送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息后褂始，再使用自己的私有密鑰進行解密诸典。利用這種方式，不需要發(fā)送用來解密的私有密鑰崎苗，也不必擔心密鑰被攻擊者竊聽而盜走赫粥。
另外次员，要根據(jù)密文和公開密文胯舷，恢復到信息原文是異常困難的黎泣，因為解密過程就是在對離散對數(shù)進行求值，這并非輕而易舉就能辦到的必尼，退一步將蒋搜，如果能對一個非常大的整數(shù)做到快速的因式分解，那么密碼破解還是存在希望的判莉。但就目前的技術看來是不太現(xiàn)實的豆挽。
3.HTTPS采用混合加密機制
HTTPS采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制。若密鑰能夠實現(xiàn)安全交換骂租，那么有可能會考慮僅使用公開密鑰加密來通信祷杈。但是公開密鑰加密與貢獻密鑰加密相比，其處理速度要慢渗饮。
所以應充分利用兩者各自的優(yōu)勢但汞，將多種方法組合起來用于通信。在交換密鑰環(huán)節(jié)使用公開密鑰加密方式互站，之后的建立通信交換報文階段則使用共享密鑰加密方式私蕾。
四、證明公開密鑰正確性的證書
遺憾的是胡桃，公開密鑰加密方式還是存在一些問題的踩叭，那就是無法證明公開密鑰本身就是貨真價實的公開密鑰，比如翠胰，正準備和某臺服務器建立公開密鑰加密方式下的通信時容贝，如何證明收到的公開密鑰就是原本預想的那臺服務器發(fā)型的公開密鑰。獲取在公開密鑰的傳輸途中之景，真正的公開密鑰已經(jīng)被攻擊者替換掉了斤富。
為了解決上述問題，可以使用由數(shù)字證書認證機構（CA 锻狗， Certificate Authority）和其相關機關頒發(fā)的公開密鑰證書满力。
數(shù)字證書認證機構處于客戶端與服務器雙方都可信賴的第三發(fā)機構的立場上焕参。威瑞信（VeriSign）就是其中一家非常有名的數(shù)字證書認證機構。我們來介紹一下數(shù)字證書認證機構的業(yè)務流程油额。首先叠纷，服務器的運營人員向數(shù)字證書認證機構日出公開密鑰的申請。數(shù)字證書認證機構在潘明提出申請者的身份之后潦嘶，會對已審核的公開密鑰做數(shù)字簽名涩嚣，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公鑰證書后綁定在一起衬以。
服務器會將這份有數(shù)字證書認證機構辦法的公鑰證書發(fā)送給客戶端缓艳，已進行公開密鑰加密方式通信。公鑰證書也可叫做數(shù)字證書或直接稱為證書看峻。
接到證書的客戶端可使用數(shù)字認證機構的公開密鑰，對那張證書上的數(shù)字簽名進行驗證衙吩，一旦驗證通過互妓，客戶端便可以明確兩件事；1認證服務器的公開密鑰的是真實有效的數(shù)字證書認證機構坤塞。2服務器的公開密鑰是值得信賴的冯勉。
此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通信方式時摹芙，如何安全轉交是一件很困難的事灼狰，因此，多數(shù)瀏覽器開發(fā)商發(fā)布版本時浮禾，會事先在內部植入常用認證機關的公開密鑰交胚。
1.可證明組織真實性的EV SSL證書
證書的一個作用是用來證明作為通信一方的服務器是否規(guī)范，另外一個作用是可確認對方服務器背后運營的企業(yè)是否真是存在盈电。擁有該特性的證書就是 EV SSL證書（Extended Validation SSL Certificate）蝴簇。
EV SSL 證書是基于國際標準的認證指導方針頒布的證書。其嚴格規(guī)定了對運營組織是否真是的確認方針匆帚，因此熬词，通過認證的web網(wǎng)站能夠獲取更高的認可度。
持有EV SSL 證書的web 網(wǎng)站的瀏覽器地址欄處的北京色是綠色的吸重，從視覺上就能一眼辨別出互拾。而且在地址欄的左側顯示了SSL證書中記錄的組織名稱以及頒發(fā)證書的認證機構的名稱。
上述機制的愿意圖是為了防止用戶被釣魚攻擊（Phishing）,但就效果上來講嚎幸，還得打一個問號颜矿。很多用戶可能不了解EV SSL證書相關的知識，因此也不太會留意它鞭铆。
2.用以確認客戶端的客戶端證書
HTTPS中換可以使用客戶端證書或衡，一客戶端證書進行客戶端認證焦影，證明服務器正在通信的對方始終是預料之內的客戶端，其作用跟服務器證書如出一轍封断。
但客戶端證書仍存在幾處問題點斯辰，其中的一個問題點是證書的獲取及發(fā)布。
想獲取證書時坡疼，用戶得自行安裝客戶端證書彬呻。由于客戶端正式是要付費購買的，且每張證書對應到每位用戶也就意味著需要支付和用戶數(shù)對等的費用柄瑰。另外闸氮，要讓知識層次不同的用戶們自行安裝證書，這件事本身也充滿了各種挑戰(zhàn)教沾。
現(xiàn)狀是蒲跨，安全性極高的認證機構可頒發(fā)客戶端證書但僅用于特殊用途的業(yè)務。比如那些可支撐客戶端證書支出費用的業(yè)務授翻。
例如或悲，銀行的網(wǎng)上銀行就是才用了客戶端證書。在登錄網(wǎng)銀時不僅要求用戶確認輸入ID和密碼堪唐，還會要求用戶的客戶端證書巡语，以確認用戶是否從特定的終端訪問網(wǎng)銀。
客戶端證書存在的另一個問題是淮菠，客戶端證書畢竟只能用來證明客戶端實際存在男公，而不能來證明用戶本人的正式有效性，也就是說合陵，只要獲得了安裝有客戶端證書的計算機的使用權限枢赔，也就意味著同時擁有了客戶端證書的使用權限。
3.認證機構信譽第一
SSL機制中介入認證機構之所以可行曙寡，是因為建立在其信用絕對可靠這一大前提下的糠爬。然而，2011年7月举庶，荷蘭的一家名叫DigiNotar的認證機構曾遭黑客不法入侵执隧，頒布了google.com和twitter.com等網(wǎng)站的偽造證書事件。這一事件從根本上撼動了SSL的可信度户侥。
因為偽造證書上有正規(guī)認證機構的數(shù)字簽名镀琉，所以瀏覽器會判定該證書是正當?shù)摹．攤卧斓淖C書被用做服務器偽裝之時蕊唐，用戶根本無法察覺到屋摔。
雖然存在可將證書無效化的證書吊銷列表（Certificate Revocation List， CRL）機制替梨，以及從客戶端刪除根證書頒發(fā)機構（Root Certificate Authority钓试，RCA）的對策装黑，但是距離生效還需要一段時間，而這段時間內弓熏，到底會有多少用戶的利益蒙受損失就不得而知了恋谭。
4.由自認證機構頒發(fā)的證書稱為自簽名證書
如果使用OpenSSL這套開源程序，每個人都可以構建一套屬于自己的認證機構挽鞠，從而自己給自己頒發(fā)服務器證書疚颊。但該服務器證書在互聯(lián)網(wǎng)上不可作為證書使用，似乎沒什么幫助信认。
獨立構建的認證機構叫做自認證機構材义，有自認證機構頒發(fā)的“無用”證書也被戲稱為自簽名證書。
瀏覽器訪問該服務器時嫁赏，會顯示“無法確認連接安全性”或“該網(wǎng)站的安全證書存在問題”等警告消息其掂。
由自認證機構頒發(fā)的服務器證書之所以不起作用，是因為它無法消除偽裝的可能性潦蝇。自認證機構能夠產(chǎn)生的作用頂多也就是自己對外宣稱“我是xx”的這種程度清寇。即使采用自簽名證書，通過SSL加密之后护蝶，可能偶爾還會看見通信處在安全狀態(tài)的提示，可那也是有問題的翩迈，因為就算加密通信持灰，也不能排除正在和已經(jīng)偽裝過的假服務器保持通信。
值得信賴的第三方機構介入認證负饲，才能讓已植入在瀏覽器內的認證機構頒布的公開密鑰發(fā)揮作用堤魁，并借此證明服務器的真實性。
中級認證機構的證書可能會變成自認證證書返十。
多數(shù)會瀏覽器內預先已植入備受信賴的認證機構的證書妥泉，但也有一小部分瀏覽器會植入中級認證機構的證書。
? ? 5）HTTPS的安全通信機制
為了更好地理解HTTPS洞坑，我們來觀察一下HTTPS 的通信步驟盲链。
步驟一：客戶端通過發(fā)送CLient Hello 報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本迟杂、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）刽沾。
步驟二：服務器可進行SSL通信時，會以Server Hello 報文作為應答排拷。和客戶端一樣侧漓，在報文中包含SSL版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的监氢。
步驟三：之后服務器發(fā)送Certificate 報文布蔗。報文中包含公開密鑰證書藤违。
步驟四：最后服務器發(fā)送Server Hello Done 報文通知客戶端嗎，最初階段的SSL握手協(xié)商部分結束纵揍，
步驟五：SSL第一次握手結束之后顿乒，客戶端以Client Key Exchange 報文作為回應。報文中包含通信加密中使用的一種被稱為Pre-master-secret 的隨機密碼串骡男。該報文已用步驟3中的公開密鑰進行加密淆游。
步驟六：接著客戶端繼續(xù)發(fā)送Change Cipher Spec 報文。該報文會提示服務器隔盛，在此報文之后的通信會采用Pre-master secret 密鑰加密犹菱。
步驟七：客戶端發(fā)送Finished報文。該報文包含連接至今全部報文的整體校驗值吮炕。這次握手協(xié)商是否能夠成功腊脱，要以服務器是否能夠正確解密該報文作為判定標準。
步驟八：服務器同樣發(fā)送Change Cipher Spec 報文龙亲。
步驟九：服務同樣發(fā)送Finished報文陕凹。
步驟十：服務器和客戶端的FInished報文交換完畢之后，SSL 連接就算建立完成鳄炉。當然杜耙，通信會受到SSL的保護。從此處開始進行應用層協(xié)議的通信拂盯，即發(fā)送HTTP請求佑女。
步驟十一：應用層協(xié)議通信，即發(fā)送HTTP響應谈竿。
步驟十二：最后由客戶端斷開連接团驱。斷開連接時，發(fā)送close_notify 報文空凸。上圖做了一些省略嚎花，這步之后再發(fā)送TCP FIN 報文來關閉與TCP的通信。
在以上流程中呀洲，應用層發(fā)送數(shù)據(jù)時會附加一種叫做MAC（Message Authentication Code）的報文摘要紊选。MAC能夠查知報文是否遭到篡改，從而保護報文的完整性两嘴。
下面是對整個流程的圖解丛楚。圖中說明了從僅使用服務器端的公開密鑰證書（服務器證書）建立HTTPS通信的整個過程。
CBC模式（Cipher Block Chaining）又名密碼分組鏈接模式憔辫。在此模式下趣些，將前一個明文塊加密處理后和下一個明文塊做XOR運算，使之重疊贰您，然后在對運算結果做加密處理坏平。對第一個明文塊做加密時拢操，要么使用前一段密文的最后一塊，那么利用外部生成的初始向量（initial vector 舶替，IV）
1.SSL和TLS
HTTPS使用SSL（Secure Socket Layer）和TLS（Transport Layer Security）這兩個協(xié)議令境。
SSL技術最初是由瀏覽器開發(fā)商網(wǎng)景通信公司率先倡導的，開發(fā)過SSL3.0之前的版本顾瞪。目前主導權已轉移到IETF（Internet Engineering Rask Force ,Internet 工程任務組）的手中舔庶。
IETF以SSL3.0為基準，后又制定了TLS1.0陈醒、TLS1.1和TLS1.2.TLS是以SSL為原型開發(fā)的協(xié)議惕橙，有時會統(tǒng)一稱該協(xié)議為SSL。當前主流的版本是SSL3.0和TLS1.0钉跷。
由于SSL1.0協(xié)議在設計之初被發(fā)現(xiàn)出了問題弥鹦，就沒有實際投入使用，SSL2.0也被發(fā)現(xiàn)存在問題爷辙，所有很多瀏覽器直接廢除了該協(xié)議版本彬坏。
2.SSL速度慢嗎
HTTPS也存在著一些問題，那就是當使用SSL時膝晾，它的處理速度會變慢栓始。
SSL的慢分兩種。一種是指通信慢血当。另一種是指由于大量消耗CPU及內存等資源混滔，導致處理速度變慢。
和使用HTTP相比歹颓，網(wǎng)絡負載可能會變慢2到100倍。除去和TCP連接油湖，發(fā)送HTTP請求響應以外巍扛，還必須進行SSL通信，因此整體上處理通信量不可避免會增加乏德。
另一點是SSL必須進行加密處理撤奸。在服務器和客戶端都需要進行加密和解密的運算處理。因此從結果上講喊括，比起HTTP會更多地消耗服務器和客戶端的硬件資源胧瓜，導致負載增強。
針對速度變慢這一問題郑什，并沒有根本性的解決方案府喳，我們會使用SSL加速器這種（專用服務器）硬件來改善該問題。該硬件為SSL通信專用硬件蘑拯，相對軟件來講钝满，能夠提高數(shù)倍SSL的計算速度兜粘。僅在SSL處理時發(fā)揮SSL加速器的功效，以分擔負載弯蚜。
為什么不一直使用HTTPS
* 既然HTTPS那么完全可靠孔轴，那為何所有的web網(wǎng)站不一直使用HTTPS？
其中一個原因是碎捺，因為與純文本通信相比路鹰，加密通信會消耗更過的CPU及內存資源，如果每次通信都加密收厨，會消耗相當多的資源晋柱，平攤到一臺計算機上時，能夠處理的請求數(shù)量必定也會隨之減少帽氓。
因此趣斤，如果是非敏感信息則使用HTTP通信，只有在包含個人信息等敏感數(shù)據(jù)時黎休，才利用HTTPS加密通信浓领。
特別是每當那些訪問量較多的web網(wǎng)站在進行加密處理時，它們所承擔著的負載不容小覷势腮，在進行加密處理時联贩，并非對所有內容都進行加密處理，而是僅在那些需要信息隱藏時才會加密捎拯，以節(jié)約資源泪幌。
除此以外，要想節(jié)約購買證書的開銷也是原因之一署照。
要進行HTTPS通信祸泪，證書是必不可少的。而是用的證書必須向認證機構（CA）購買建芙。證書價格可能會根據(jù)不同的認證機構略有不同没隘。
那些購買證書并不合算的服務以及一些個人網(wǎng)站，可能只會選擇采用HTTP的通信方式禁荸。
