1.HTTP

?HTTP在傳輸數(shù)據(jù)時，通常都是明文傳輸，也就是傳輸?shù)臄?shù)據(jù)沒有進(jìn)行加密。在這種情況下，如果傳輸?shù)氖且恍┟舾袛?shù)據(jù)，比如某銀行卡密碼，就很容易被別人截獲到，這就對我們的個人利益產(chǎn)生了威脅。

HTTP傳輸數(shù)據(jù)時，數(shù)據(jù)安全無法得到保證：

2. HTTPS

如今，大多數(shù)網(wǎng)站使用的都是HTTPS。

對于HTTP的機(jī)制，HTTPS也同樣適用。它們的區(qū)別在于，HTTPS在HTTP的基礎(chǔ)上，在數(shù)據(jù)安全方面做了進(jìn)一步改進(jìn)。也就是說，HTTPS是基于HTTP，且進(jìn)一步保證了數(shù)據(jù)的安全。

不加密的數(shù)據(jù)，放在網(wǎng)絡(luò)中傳輸，就相當(dāng)于"裸奔"，黑客很容易就能獲取到相關(guān)數(shù)據(jù)。數(shù)據(jù)安全問題受到了極大的威脅。?

因此，在進(jìn)行網(wǎng)絡(luò)通信時，更安全的做法是，將傳輸?shù)臄?shù)據(jù)進(jìn)行加密，特別是一些重要的數(shù)據(jù)，將數(shù)據(jù)加密之后，就算有人利用一些手段獲取到了我們傳輸?shù)臄?shù)據(jù)，但由于數(shù)據(jù)是經(jīng)過加密的，別人也很難破解數(shù)據(jù)，這樣就在一定程度上保證了數(shù)據(jù)安全，HTTPS就做到了。

因此，如今大多數(shù)網(wǎng)站使用的都是HTTPS，HTTPS會將數(shù)據(jù)進(jìn)行加密，加密的方式有：對稱加密 和 非對稱加密。?

2.1 對稱加密

對稱加密，就是 客戶端生成一個密鑰，通過該密鑰，可以對數(shù)據(jù)進(jìn)行 加密 和 解密?？蛻舳讼蚍?wù)器發(fā)送數(shù)據(jù)時，就會通過該密鑰將數(shù)據(jù)進(jìn)行加密，并將密鑰傳給服務(wù)器。

當(dāng)服務(wù)器拿到數(shù)據(jù)和密鑰后，就可以通過密鑰對數(shù)據(jù)進(jìn)行解密，從而拿到數(shù)據(jù)原文。不同的客戶端，生成的密鑰都不相同，因此服務(wù)器拿到不一樣的密鑰，就可以對 相應(yīng)的數(shù)據(jù) 進(jìn)行解密。

?

此時就存在一個問題，黑客也可以在數(shù)據(jù)傳輸?shù)倪^程中，將密鑰獲取到，從而拿到數(shù)據(jù)原文，此時對 數(shù)據(jù)加密 也就形同虛設(shè)了。因此，密鑰也應(yīng)該被加密，這樣即使黑客拿到密鑰，但無法破解? ?加密的? 密鑰，就無法獲取到原文數(shù)據(jù)了。對 密鑰加密 就要需要 非對稱加密 方式的幫助了。

2.2 非對稱加密

非對稱加密，則是服務(wù)器生成一對兒密鑰，分別是 公鑰m1 和 私鑰m2?？梢酝ㄟ^公鑰對數(shù)據(jù)進(jìn)行加密，再通過私鑰 對數(shù)據(jù)進(jìn)行解密，反之也可。

雙方在通信時，客戶端會拿到 服務(wù)器持有的公鑰m1，客戶端也會以 對稱加密 的方式生成一個密鑰n?？蛻舳藭ㄟ^密鑰n對數(shù)據(jù)加密，通過公鑰m1對密鑰n加密。

加密完成后，客戶端就將 密文 和 加密后的密鑰 發(fā)送給服務(wù)器，服務(wù)器就可以通過 私鑰m2對加密過的 密鑰 進(jìn)行解密，拿到密鑰原文。再通過 對稱密鑰n 對密文進(jìn)行解密，從而拿到數(shù)據(jù)原文。

因此，對稱加密 和 非對稱加密 相結(jié)合，https使得數(shù)據(jù)安全得到了進(jìn)一步保證，黑客想拿到數(shù)據(jù)原文，只獲取到 加密的密鑰 和 加密的數(shù)據(jù)，是不夠的，因為黑客難以破解加密的密鑰。

對稱加密 和 非對稱加密 兩種方式相結(jié)合，通信過程如下：

通過以上方式，以?非對稱加密的方式?對 對稱密鑰?加密，再通過 對稱加密?對數(shù)據(jù)加密，從而保證數(shù)據(jù)的安全傳輸。這是 對稱加密?和 非對稱加密?兩種加密方式的結(jié)合 來支持?jǐn)?shù)據(jù)安全。

沒有僅僅使用 非對稱加密方式 來實現(xiàn)安全傳輸?shù)?原因就在于 使用非對稱加密 方式 所造成的成本開銷較大，使得傳輸效率較低。因此 兩種加密方式 相結(jié)合，不僅保證了數(shù)據(jù)的安全傳輸，也盡可能的減少開銷成本。

此時，又有一個新的漏洞，即使 HTTPS 以 非對稱加密 和 對稱加密 相結(jié)合來傳輸數(shù)據(jù)，黑客仍能找到漏洞，將 服務(wù)器發(fā)送過來的 公鑰 進(jìn)行"偷梁換柱"，從而竊取到數(shù)據(jù)，漏洞如下：

于是，黑客 就在數(shù)據(jù)的傳輸過程中 悄無聲息的 做了手腳，客戶端沒有發(fā)現(xiàn)問題，服務(wù)器也沒有發(fā)現(xiàn)問題，但數(shù)據(jù)已經(jīng)被黑客竊取了。

因此，僅僅使用 對稱加密 和 非對稱加密 并不能真正保證數(shù)據(jù)的安全傳輸。客戶端無法辨別自己收到的 公鑰 到底是不是 服務(wù)器發(fā)過來的，無法完全信任。于是，就引入了第三方公證機(jī)構(gòu)，客戶端和服務(wù)器 都信任這個第三方機(jī)構(gòu)，第三方機(jī)構(gòu)就能 幫助客戶端 鑒別這個公鑰是否是服務(wù)器的公鑰。

2.3 第三方公證機(jī)構(gòu)

每個服務(wù)器在搭建的時候，都會以 非對稱加密方式 生成一對兒 密鑰，并且向 公證機(jī)構(gòu) 提交審核材料(域名，服務(wù)器公鑰，廠商等相關(guān)信息)。?公證機(jī)構(gòu)就會對 材料進(jìn)行審核，資質(zhì)審核沒問題的話，就會給服務(wù)器頒發(fā)一個證書(一段結(jié)構(gòu)化數(shù)據(jù))，服務(wù)器則會保存好證書。

證書中的內(nèi)容就包括 網(wǎng)站的域名，服務(wù)器的公鑰，數(shù)字簽名(頒發(fā)證書的時候，公證機(jī)構(gòu)會根據(jù)證書的相關(guān)屬性 計算出一個 校驗和，并且公證機(jī)構(gòu)也會 以 非對稱加密 方式 生成一對兒 密鑰，并且自己將私鑰保留著，公鑰則內(nèi)置在 客戶端的設(shè)備中。公證機(jī)構(gòu) 通過 私鑰 對 校驗和加密，加密后的 校驗和 就是 數(shù)字簽名)等信息。

客戶端向服務(wù)器發(fā)送信息之前，會先向服務(wù)器 索要證書。客戶端收到服務(wù)器發(fā)送過來的證書，也就收到了 服務(wù)器的 公鑰。收到證書后，客戶端會有一個 "證書校驗"的過程。這個過程就是為了 驗證 證書中的公鑰是不是服務(wù)器生成的公鑰。

證書校驗：校驗的核心在于 “數(shù)字簽名”，客戶端通過設(shè)備內(nèi)置的公鑰 對數(shù)字簽名解密，從而拿到 校驗和?？蛻舳?strong>再通過相同的方式 計算一遍校驗和，如果自己計算的校驗和 和 服務(wù)器發(fā)來的校驗和 一致的話，則說明這個公鑰就是 服務(wù)器的公鑰。于是，客戶端就可以放心的使用 服務(wù)器發(fā)來的公鑰了。

有了以上過程，黑客就很難再竊取到數(shù)據(jù)了，即使黑客在客戶端收到證書之前，先對證書進(jìn)行篡改，比如 修改公鑰(如果黑客替換了了服務(wù)器的公鑰，那么客戶端在進(jìn)行校驗和計算的時候，計算的校驗和結(jié)果則會與證書中的校驗和不一致)，修改數(shù)字簽名(既然無法替換公鑰，干脆 黑客直接替換公鑰，再替換 數(shù)字簽名。但 數(shù)字簽名 是被 公證機(jī)構(gòu)的 私鑰 加密過的，且公鑰在客戶端設(shè)備上，黑客無法拿到 校驗和原數(shù)據(jù))，申請一個證書(服務(wù)器的證書內(nèi)容無法更改的話，黑客能否直接申請一個證書，直接在服務(wù)器證書的傳輸過程中，直接替換掉證書，但是 申請證書有資質(zhì)審核的環(huán)節(jié)，因此黑客無法申請到證書)。

【總結(jié)HTTPS加密機(jī)制】

（1）通過 對稱加密 和 非對稱加密 相結(jié)合，對 數(shù)據(jù) 和 密鑰 加密；

（2）再引入 第三方公證機(jī)構(gòu)，防止 有人 "偷梁換柱"，替換服務(wù)器的公鑰。

通過以上方式的相結(jié)合，HTTPS就可以在?極大程度上 保證了 數(shù)據(jù)的安全傳輸。因此，如今絕大多數(shù)的網(wǎng)站使用的都是HTTPS。文章來源地址http://www.zghlxwxcb.cn/news/detail-853916.html

到了這里，關(guān)于HTTP和HTTPS誰傳輸數(shù)據(jù)更安全？的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！