今天忽然收到郵件說SSL不能用了,基於SSL的HTTPS協議不通了,怎麼辦? java/android 的網絡編程簡直一竅不通,平時都是用到了問百度。只能惡補有關網絡的知識了。html
傳輸協議:java
傳輸協議中各層都爲上一層提供業務功能。爲了提供這種業務功能,下一層將上一層中的數據併入到本層的數據域中,而後經過加入報頭或報尾來實現該層業務功能,該過程叫作數據封裝。用戶的數據要通過一次次包裝,最後轉化成能夠在網絡上傳輸的信號,發送到網絡上。當到達目標計算機後,再執行相反的拆包過程。這相似於平常生活中寫信,把本身要表達的意思寫到紙上,有興趣的話還要把紙摺疊成特殊的形狀,而後放到信封裏並封好口,寫好收信人的地址、郵政編碼和姓名,再貼上郵票,郵局的工做人員再蓋上郵戳送到收信人所在郵局,郵遞員按信上的地址把信交給收信人,收信人再拆信,閱讀其內容。android
SSL協議:web
SSL協議位於TCP/IP協議與各類應用層協議之間,爲數據通信提供安全支持。SSL協議可分爲兩層: SSL記錄協議(SSL Record Protocol):它創建在可靠的傳輸協議(如TCP)之上,爲高層協議提供數據封裝、壓縮、加密等基本功能的支持。 SSL握手協議(SSL Handshake Protocol):它創建在SSL記錄協議之上,用於在實際的數據傳輸開始前,通信雙方進行身份認證、協商加密算法、交換加密密鑰等。算法
SSL協議提供的服務主要有:編程
1)認證用戶和服務器,確保數據發送到正確的客戶機和服務器;瀏覽器
2)加密數據以防止數據中途被竊取;安全
3)維護數據的完整性,確保數據在傳輸過程當中不被改變。服務器
SSL協議的工做流程:網絡
服務器認證階段:1)客戶端向服務器發送一個開始信息「Hello」以便開始一個新的會話鏈接;2)服務器根據客戶的信息肯定是否須要生成新的主密鑰,如須要則服務器在響應客戶的「Hello」信息時將包含生成主密鑰所需的信息;3)客戶根據收到的服務器響應信息,產生一個主密鑰,並用服務器的公開密鑰加密後傳給服務器;4)服務器恢復該主密鑰,並返回給客戶一個用主密鑰認證的信息,以此讓客戶認證服務器。
用戶認證階段:在此以前,服務器已經經過了客戶認證,這一階段主要完成對客戶的認證。經認證的服務器發送一個提問給客戶,客戶則返回(數字)簽名後的提問和其公開密鑰,從而向服務器提供認證。
從SSL 協議所提供的服務及其工做流程能夠看出,SSL協議運行的基礎是商家對消費者信息保密的承諾,這就有利於商家而不利於消費者。在電子商務初級階段,因爲運做電子商務的企業大可能是信譽較高的大公司,所以這問題尚未充分暴露出來。但隨着電子商務的發展,各中小型公司也參與進來,這樣在電子支付過程當中的單一認證問題就愈來愈突出。雖然在SSL3.0中經過數字簽名和數字證書可實現瀏覽器和Web服務器雙方的身份驗證,可是SSL協議仍存在一些問題,好比,只能提供交易中客戶與服務器間的雙方認證,在涉及多方的電子交易中,SSL協議並不能協調各方間的安全傳輸和信任關係。在這種狀況下,Visa和 MasterCard兩大信用卡公組織制定了SET協議,爲網上信用卡支付提供了全球性的標準。
TLS:安全傳輸層協議
Short for Transport Layer Security, a protocol that guarantees privacy and data integrity between client/server applicationscommunicating over the Internet.
The TLS protocol is made up of two layers:
TLS is application protocol-independent. Higher-level protocols can layer on top of the TLS protocol transparently.
https介紹
HTTPS(Secure Hypertext Transfer Protocol)安全超文本傳輸協議
它是由Netscape開發並內置於其瀏覽器中,用於對數據進行壓縮和解壓操做,並返回網絡上傳送回的結果。HTTPS實際上應用了Netscape的徹底套接字層(SSL)做爲HTTP應用層的子層。(HTTPS使用端口443,而不是象HTTP那樣使用端口80來和TCP/IP進行通訊。)SSL使用40 位關鍵字做爲RC4流加密算法,這對於商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證,若是須要的話用戶能夠確認發送者是誰。。
https是以安全爲目標的HTTP通道,簡單講是HTTP的安全版。即HTTP下加入SSL層,https的安全基礎是SSL,所以加密的詳細內容請看SSL。
它是一個URI scheme(抽象標識符體系),句法類同http:體系。用於安全的HTTP數據傳輸。https:URL代表它使用了HTTP,但HTTPS存在不一樣於HTTP的默認端口及一個加密/身份驗證層(在HTTP與TCP之間)。這個系統的最初研發由網景公司進行,提供了身份驗證與加密通信方法,如今它被普遍用於萬維網上安全敏感的通信,例如交易支付方面。
最新版本的TLS(Transport Layer Security,傳輸層安全協議)是IETF(Internet Engineering Task Force,Internet工程任務組)制定的一種新的協議,它創建在SSL 3.0協議規範之上,是SSL 3.0的後續版本。在TLS與SSL3.0之間存在着顯著的差異,主要是它們所支持的加密算法不一樣,因此TLS與SSL3.0不能互操做。
1.TLS與SSL的差別
1)版本號:TLS記錄格式與SSL記錄格式相同,但版本號的值不一樣,TLS的版本1.0使用的版本號爲SSLv3.1。
2)報文鑑別碼:SSLv3.0和TLS的MAC算法及MAC計算的範圍不一樣。TLS使用了RFC-2104定義的HMAC算法。SSLv3.0使用了類似的算法,二者差異在於SSLv3.0中,填充字節與密鑰之間採用的是鏈接運算,而HMAC算法採用的是異或運算。可是二者的安全程度是相同的。
3)僞隨機函數:TLS使用了稱爲PRF的僞隨機函數來將密鑰擴展成數據塊,是更安全的方式。
4)報警代碼:TLS支持幾乎全部的SSLv3.0報警代碼,並且TLS還補充定義了不少報警代碼,如解密失敗(decryption_failed)、記錄溢出(record_overflow)、未知CA(unknown_ca)、拒絕訪問(access_denied)等。
5)密文族和客戶證書:SSLv3.0和TLS存在少許差異,即TLS不支持Fortezza密鑰交換、加密算法和客戶證書。
6)certificate_verify和finished消息:SSLv3.0和TLS在用certificate_verify和finished消息計算MD5和SHA-1散列碼時,計算的輸入有少量差異,但安全性至關。
7)加密計算:TLS與SSLv3.0在計算主密值(master secret)時採用的方式不一樣。
8)填充:用戶數據加密以前須要增長的填充字節。在SSL中,填充後的數據長度要達到密文塊長度的最小整數倍。而在TLS中,填充後的數據長度能夠是密文塊長度的任意整數倍(但填充的最大長度爲255字節),這種方式能夠防止基於對報文長度進行分析的攻擊。
2.TLS的主要加強內容
TLS的主要目標是使SSL更安全,並使協議的規範更精確和完善。TLS 在SSL v3.0 的基礎上,提供瞭如下加強內容:
1)更安全的MAC算法;
2)更嚴密的警報;
3)「灰色區域」規範的更明確的定義;
3.TLS對於安全性的改進
1)對於消息認證使用密鑰散列法:TLS 使用「消息認證代碼的密鑰散列法」(HMAC),當記錄在開放的網絡(如因特網)上傳送時,該代碼確保記錄不會被變動。SSLv3.0還提供鍵控消息認證,但HMAC比SSLv3.0使用的(消息認證代碼)MAC 功能更安全。
2)加強的僞隨機功能(PRF):PRF生成密鑰數據。在TLS中,HMAC定義PRF。PRF使用兩種散列算法保證其安全性。若是任一算法暴露了,只要第二種算法未暴露,則數據仍然是安全的。
3)改進的已完成消息驗證:TLS和SSLv3.0都對兩個端點提供已完成的消息,該消息認證交換的消息沒有被變動。然而,TLS將此已完成消息基於PRF和HMAC值之上,這也比SSLv3.0更安全。
4)一致證書處理:與SSLv3.0不一樣,TLS試圖指定必須在TLS之間實現交換的證書類型。
5)特定警報消息:TLS提供更多的特定和附加警報,以指示任一會話端點檢測到的問題。TLS還對什麼時候應該發送某些警報進行記錄。
參考:http://www.webopedia.com/TERM/T/TLS.html
http://hengstart.iteye.com/blog/840561
百度百科