TCP/IP跨主機之間的通信數據封裝發送的都是明文數據，現代通訊中會有安全問題。
三個安全問題
如：A發送消息給B的三個安全問題
機密性：明文傳輸如：ftp,http,smtp,telnet等
完整性：數據可能被篡改（舉例:電商下單生產數量或者傳輸過程信號錯亂）
身份驗證：A和B從未見過（舉例:釣魚網站冒名頂替，保證對方即是其所聲稱的身份）
解決上述三個問題可以通過加密算法的混合使用，常見加密算法有如下
對稱加密
DES：數據加密標准，早期使用的56bit密鑰
3DES：Triple DES 對每個數據塊應用三次DES加密
AES：高級加密標准128bit默認，還有AES192、AES256、AES512
單向加密
MD5
SHA1 輸出長度為160
SHA192/SHA256/SHA384 輸出長度
公鑰加密：核心功能是數據加密和簽名
RSA：實現加密和簽名，部分公開使用
DSA：只實現簽名，公開使用
數字簽名是什么？
三個問題的解決
機密性假如傳輸數據abc，為了不讓互聯網上的其他人獲取，就要加密，那么如何加密呢？加密就是轉換規則，把明文轉換成密文，plaintext-->轉換規則-->ciphertext。
如果其他人獲得了轉換規則（算法）怎么辦？通常更換的是秘鑰而不是算法，設計思想是靠秘鑰保證機密性而非算法，換秘鑰更簡單
加密算法--對稱加密：用於加密任意大小的數據塊數據內容，加密方和解密方使用的是同一個密碼，加密速度快。如：A要與BCDEF…通信，各方不同密鑰，密鑰管理復雜。缺點：通信對象多的時候，無法有效對密鑰管理。
↓↓
完整性如何保證數據不被篡改？加密算法—單向加密：抽取數據的特征碼。把特征碼附加在原文之后一並發送。
單向加密特性：
輸入一樣，輸出必然一樣；
雪崩效應，輸入的微小改變，將會引起結果的巨大改變；
無論原始數據是多少，結果大小都是相同的；
不可逆，無法根據特征碼還原原來的數據
中間人攻擊：修改數據和特征碼重新發送。所以數據完整性的手段無法保證完整性本身，要借助其他機制——加密特征碼。特征碼能夠使用對稱加密，可是在兩個人第一次通信時，由於互相都不知道對方的密鑰，在網絡上傳輸密鑰時是明文傳輸的，密鑰安全性不能得到保證。
如何實現雙方協商密鑰，但是卻不讓第三方得到密鑰？——密鑰交換
最早的Diffie-Hellman IKE（Internet Key Exchange）互聯網密鑰交換
①A、B各自選擇兩個數字p,g(大素數，生成數)
②A、B各自生成自己的隨機數x,y
③A:g^x%p—>B B:g^y%—>A 把計算結果發給對方
④A:(g^y%p)^x=g^yx%p(結果就是密鑰) B:(g^x%p)^y=g^xy%p
通過這種方式，雙方只知道自己的x,y，但是經過計算可以在未知對方x或y的情況下得到相同的一個數值（g^xy%p）
↓↓
密鑰交換后可以加密特征碼，可是還是沒有解決問題，仍然無法驗證對方身份
如何驗證對方身份？催生第三種加密算法產生--公鑰加密算法
公鑰加密（非對稱加密）加密和解密使用的是不同的密碼，有公鑰和私鑰，密鑰是成對出現的，公鑰是從私鑰中提前出來的，私鑰是很長的，私鑰加密速度比較慢。公鑰是公開的，公鑰加密需要用私鑰解密，用私鑰加密得用公鑰解密。
用對方公鑰加密數據，可以保證機密性。發送方用自己私鑰加密，可以實現身份驗證
公鑰加密算法速度太慢，不適用於加密數據，慢於對稱加密三個數量級，用於身份驗證
結合兩種加密（保證完整性+身份驗證）
使用私鑰加密特征碼，中間人能解密可以修改數據，但是接收方可以發覺。這一切的保證就是公鑰，那么從哪里獲得公鑰？
↓↓
如何保證不是中間人的公鑰，只能借助於第三方機構。
這里最重要的一步就是公鑰的獲取，如何得到對方的公鑰，又如何得知一定是對方的公鑰？
此時就需要依賴於CA，每個人所發的公鑰對方無法驗證其真假，就像你說自己是xx，那怎么證明你就是xx呢？生活中我們都是通過身份證來驗證的，但是身份證不能你自己做一張印上一個名字，就說自己叫xx，需要提供一張由公安部門所頒發的權威的身份證才能得到認可，因為大家是信任公安部門的權威性的。這里把公安部門稱為第三方機構也即是這里的CA。AA和BB通信之前要向CA去注冊認證自己的身份。
AA向CA申請給自己發一個證（里面包含公鑰、名字、有效期等CA會使用單向加密計算這些數據特征碼，CA再用自己的私鑰加密這段特征碼並附加在證書的后面，即數字簽名，保證了證書的信息沒有被更改），AA就把自己的證給BB，那此時BB如何去驗證AA發來的證書不是偽證書？則BB需要信任CA，才能信任CA所頒發的證書，BB使用CA的公鑰解密這段特征碼，再用相同的單向加密計算這些數據特征碼，比較兩個特征碼是否一致。
獲取到CA的證書就包含了CA的公鑰，此時CA的證書（公鑰）從何而來呢？CA是自己給自己給發證書的。用自身的私鑰給包含公鑰的證書簽名。如何判斷獲得的CA的證書就是發證機關的？無法保證。你可以到頒發機構本地復制證書，還有一些電子商務網站，你信任這些網站，你訪問時就安裝它的證書。且需要提供有公信力CA是需要向根CA注冊申請，都是需要收費的。
雖然私鑰把特征碼加密附到源數據一起發送可以解決完整性和身份驗證問題，但是數據仍然未加密，此時通過秘鑰交換形成的對稱秘鑰把有附加信息的源數據整體再次加密就能解決機密性問題。
秘鑰交換除了上述的DH算法，也可以通過對稱秘鑰來實現
以隨機生成一個數當加密密鑰，用接收方的公鑰加密后加在數據后面發送出去，接收方用私鑰解密獲得對稱密鑰，用對稱密鑰解密數據，最后用私鑰解密特征碼。
證書
證書頒發機構和彼此間的信任關系述組成了PKI（public key infrastructure公鑰基礎設施），基本組成如下：
簽證機構：CA
注冊機構：RA
證書吊銷列表：CRL
證書存取庫：
證書頒發機構（根證書頒發機構）派發出子機構 ，稱為RA，用於接受證書申請，最后發給CA簽名。
還有一種特殊情況，如果說證書（私鑰）丟失了，該如何處理呢？私鑰丟了，必須讓獲得公鑰的主機知道公鑰被廢了，因此CA機構需要維持一張列表（證書吊銷列表），一旦私鑰丟棄，則向CA申請自己的證書作廢。CA機構就把丟失私鑰的主機放到證書吊銷列表中。
crl：證書吊銷列表，Certificate Revocation List；保存此前發出的仍未過期但被撤銷的證書。則通信時，還需要增加一步就是通信的對方收到數據后，需要到CA機構查看發送方是否在證書吊銷列表中。（注意互聯網上絕大部分通信者都沒有這樣做，因此互聯網上通信還是存在安全隱患的）
一個證書中應該包含什么？
不同標准下的證書格式是不同的，主流的標准格式如x509（國際電信聯盟ITU-T 制定），包含 
主體名稱：證書的合法擁有者
附加在最后是通過CA私鑰簽名的證書特征碼
獲取證書就是為了獲得對方公鑰，如何驗證證書
1、利用本地預存的公鑰信息，解密頒發機構的簽名
2、解密獲得證書的特征碼，驗證此證書內容沒有被篡改
3、聯系證書頒發機構確認證書有效可用
有兩種PKI：TLS/SSL使用的是x509的證書；OpenGPG是另一種證書管理機制（或者叫PKI的實現架構）
另外為了驗證證書不是由偽裝的CA頒發的，必須通過可靠的途徑來獲取可信任CA的公鑰（如廠商之間互相信任內置公鑰）