用 http 數據加密和 https 有什麼區別？

12-28

https 是將傳輸數據加密，如果用 http 協議但將數據加密後再進行傳輸，這兩者有什麼區別，我覺得沒什麼區別

在信息安全方面有一個不成文的共識，就是儘可能不要自己造輪子，而是用那些成熟的、經過千錘百鍊的輪子。

每個喜好鑽研的程序員都免不了冒出這種念頭：如果我自己發明出一種不為人知的加密演算法，會不會比公開的演算法更安全，能避免被破解？比如「用新演算法加密http，替代https」。

不會，起碼在https這個問題上絕對不可能。

下面來詳細解釋一下直接加密http數據來替代https會有哪些問題：

第一，性能問題。這一條最容易理解，瀏覽器通過http收到加密數據後，需要用javascript來執行解密演算法，而https是瀏覽器原生支持的，兩者的性能差距可能高達一到兩個數量級。就算所有的安全問題都解決了，也不推薦這麼做；

第二就是兼容性問題了。https其實不是單一演算法，而是一系列演算法和加密協議的整合。

從早期的SSL3.0一直進化到今天的TLS1.2以及起草中的TLS1.3協議；

密鑰交換階段的RSA、DHE等非對稱加密演算法；

加密信息傳輸過程中的AES、3DES等對稱加密演算法；

驗證數據完整性的HMAC-SHA1、HMAC-SHA256等哈希演算法；

包括使用中的和被淘汰的，林林總總合計有幾十種之多。

而且隨著攻擊方式的進化和安全性要求的不斷提升，新的演算法不停加入，舊的演算法不停被淘汰。

由於不同客戶端和伺服器所支持的演算法類型有新有舊，所以任何https連接建立之前都要進行協商，選擇雙方都能支持又足夠安全的演算法後再進行加密連接。

那麼，在客戶端和服務端也都要同時維護不斷進化的加密演算法並進行協商，保證版本兼容性。否則這種加密協議就永遠不能推廣，只能在少數私有項目中使用。

第三，也是最重要的，我們來看看這種加密的的安全性如何吧，有多少地方可能被攻破。

我們假設性能不是問題，兼容性也暫不考慮，只討論安全性。

javascript這種直接暴露源碼的語言，就算混淆過也沒有什麼秘密可言，甚至能直接在瀏覽器中debug、引入插件、載入外部腳本等。單這點就遠不如瀏覽器這種獨立應用程序了，至少對瀏覽器進行惡意修改和注入的行為理論上是能被殺毒軟體攔截的。

那麼把外殼的安全也放在一邊，僅說加密演算法行不行？

先排除掉純對稱加密的方式。因為密鑰通過明文傳輸，無論是預置還是每次更換都難以避免被截獲。

那就只好重新造一次SSL/TLS的輪子了，即先通過RSA加密傳輸對稱密鑰，再通過此密鑰加密往來數據。

但這樣依然不行。儘管RSA是非對稱演算法，能保證加解密過程的安全，但公鑰本身的傳輸仍然是可以被截獲並篡改的。正如針對https的中間人攻擊一樣，如果在握手階段偽造了公鑰，則能夠輕易截獲之後的所有通信。https防範中間人攻擊的方式是CA證書，所有網站證書都通過CA證書體系一級一級信任下來，而根證書是內置於操作系統中的，需要相當高的許可權才能操作（當然不能百分百防範，但已經是很高的安全措施了）。

但如果把整套證書安全機制放在js腳本里執行，那跟原來相比簡直是天上地下的差距，毫無安全性可言了。

以上只做了一些簡單分析，自己開發的http加密就已經潰不成軍。而且結論還建立在代碼本身沒有缺陷、沒有漏洞的情況下。js這種弱類型語言出bug的幾率有多高就不用多提了吧？

這並不是說自己造的輪子都毫無價值，出於學習和研究目的而編寫演算法甚至實現一些框架都是有意義的。但對於正式應用而言，永遠是那些公開的、被廣泛應用的技術方案更加靠譜。

開發一種不為人知的加密演算法就像隱居山林的武術大師，憑想像構建了一套天下無敵的神奇功夫，但不出山則已，一出山就直接被業餘散打運動員撂翻在地。只有每天都進行對抗訓練，經受各種實戰考驗，才有可能成為真正的武林高手。

將數據加密然後http傳輸，當然可以。當你把安全性的各種問題都考慮完善並且實現了，那麼恭喜你，你把https協議做出來了。

有區別。

從協議設計角度來公平地正面比較，「用 http 協議但將數據加密後再進行傳輸" 缺了密鑰協商 + 證書認證兩大塊安全特性。

導致的安全缺陷是：

1. 缺失 DH/ECDH 密鑰協商。

不使用DH/ECDH等密鑰協商演算法的任何密鑰共享方案都是有缺陷的。

比如常見的客戶端寫死密鑰，那可以逆向客戶端破出來隨意篡改通信內容；

又或者通過信道傳遞的密鑰，那可以在中間截獲，隨意篡改通信內容。

或者隨便你設想的任何別的更複雜的密鑰共享手段，翻開一本密碼學入門教材的密鑰交換章節，基本都可以找到破解方法。

2. 缺失基於證書 pki 體系的身份認證。

缺失身份認證，導致中間人可以偽造身份，進行 MITM 攻擊，隨意劫持篡改通信內容。

假設投入人力物力財力，補上了這兩大塊功能，那就得到了一個乞丐版的 tls。（況且目前來看， pki 證書在 js裡面根本就無法實現，因為必須要瀏覽器內置才行，不能通過http傳輸證書）

還缺失 session cache 性能優化（沒有 session cache ，性能大概比 tls 差 1000 倍吧），等等重要功能，性能上還是會被標準TLS 協議吊打。

假設再投入人力物力財力，把 session cache 什麼的也補上了，那就得到了標準 TLS 協議。

然後算一下投入產出比就發現，投入的這些研發資金，全都白白浪費掉了。還 TMD 不如一開始就用 HTTPS，開源軟體 nginx/openssl 零開發成本，配置一下分分鐘上線.。遂吐血卒。

古語云：言多必失！其內涵不用我解釋，我的理解是：暴露的越多，越容易被別人找到弱點和漏洞。

在網路安全加密方案的比較中，我們也遵循這個法則，最安全的方案一定是暴露用戶信息最少的，換句話說：加密的越多，越安全！

能夠提供端到端安全的加密方案有：

1 ）網路層加密

2 ）傳輸層加密

3 ）應用層加密

不言而喻，網路層（IPsec）加密了除IP之外的所有層，包括TCP/UDP及以上，加密用戶信息最多。

傳輸層加密（TLS）加密了除IP/TCP/UDP之外，所有應用層數據，包括 HTTP/FTP/SMTP，加密內容次之。

應用層加密，只是加密應用層里敏感的信息，如密碼，以及其它需要加密保護的內容，那IP/TCP/HTTP內容都明文暴露在外，加密內容最少。

毫無疑問，網路層加密IPsec是最安全的！但網路層加密為何沒有傳輸層TLS加密那麼流行而普及呢？那是因為IPsec需要預先配置，甚至要安裝客戶端軟體，這一點是非常致命的，嚴重影響其普及程度。

而基於TLS的安全加密如HTTPS，幾乎不需要任何預先配置。只要瀏覽器擁有Root CA證書，或其二級RA簽發的證書，則安全加密是自動進行的，無須用戶任何干預。對於用戶來說，還有什麼比傻瓜式訪問更好的嗎？

即使瀏覽器沒有所訪問的HTTPS網站的Root CA證書、或其二級證書，如HTTPS://12306.cn，也會在第一次訪問網站時，被要求下載並安裝證書，接下來的安全加密也是自動進行，而無需用戶的干預。

認證對端合法性、密鑰交換演算法、加密演算法、MAC校驗演算法、防重放攻擊，IPsec 與TLS沒有任何區別，大家都使用同一班人馬：

1 認證對端合法性（Authentication）

1.1 Pre-shared Password

1.2 PKI

2 密鑰交換演算法（Key Exchange）

2.1 RSA

2.2 DH

3 加密演算法（Encryption）

3.1 AES

3.2 3DES

4 MAC校驗演算法（Integrity)

4.1 MD5

4.2 SHA-1

5 防重放攻擊（ Anti-Replay）

對於這個一般都使用序列號（Sequence Number）來杜絕重放攻擊

以上的5點囊括了安全加密的核心理念，最初被使用在IPsec加密中，歷經了很多考驗與不斷完善中，後來又將這個接近完美的方案應用於TLS加密中，即使這樣，其最薄弱的環節，認證對方合法性（中間人欺騙），依然存在。（這也是致命的，因為一步錯，步步錯）

如果應用層加密，依然要遵循以上5個步驟，才會擁有真正的安全，但如果也採用這5個步驟，那為何不讓TLS來完成呢？

我的觀點是：使用TLS來加密HTTP數據，如果客戶端和伺服器端都為私有實現，使用預共享密鑰生成 敏感數據加密+ MAC，將數據HTTP封裝，然後由TLS加密，這樣即使有中間人欺騙，也無法解密應用層加密數據，安全級別最高。

目前廣泛使用的APP，由於客戶端、伺服器端都為同一公司開發，可以實現我提到的私有實現，即使用兩層加密，由於預共享密鑰可以杜絕中間人欺騙，所以是安全的。

有區別的。哪怕你代碼寫得跟https一樣好，演算法一樣健壯，但是Windows的https是（可以）跑在內核里的，永遠比你快。

其實簡單的加密後通過http傳輸，和使用https（http over ssl/tls）傳輸到底有什麼區別呢？

https除了傳輸層安全，還有身份認證的功能，常見的是客戶端對服務端進行身份認證，也支持服務端對客戶端進行身份認證。

不用https，將數據加密後通過http傳輸，你是用對稱加密演算法呢，還是非對稱加密演算法呢？

如果是對稱加密演算法，客戶端怎麼通過明文通道http獲得服務端的密鑰呢？（反之亦然），安全嗎？多長時間換一把密鑰呢？

如果是非對稱加密演算法，一方面也是要把自己的公鑰傳給對方，另一方面，非對稱加密性能不高。

如果考慮到網路攻擊，把機制搞得健全點，交換公鑰，生成非對稱密鑰，用非對稱加密對對稱密鑰進行加密在http上傳輸（解決了密鑰交換的問題），然後傳輸http消息時用對稱密鑰加密（解決了非對稱加密性能不高的問題），這就變成https了。

還有一個區別就是，一個是在http層以下加密，在tcp連接建立後通過幾個來回交換密鑰，再傳送http消息，消息作為整體加密，客戶端/服務端程序不需要感知是否加密。另一個是在http之上，http消息中的元素要分別加密，比如url，header name/value，entity，客戶端/服務端都需要感知，web伺服器和服務端程序的介面如CGI，Servlet，WSGi，都是基於http協議提供的編程模型，要麼交給Web伺服器解密，要不由服務端程序解密，而後者增加了編程的複雜性。

https保護了

1. 認證，雙方通信是可信可證實體
2. 密鑰交換，密鑰是不會泄露的
3. 機密性
4. 完整性
5. 新鮮性
6. 完美前向安全

機密性只是其中的一個保護，其他保護更重要

從原理上來說，題目的觀點沒錯，「加密內容在公開信道傳輸」並不比「未加密內容在加密信道傳輸」更不安全；但是，在實際應用中，還是有不同的：前一種方式下，接收方要解密內容，就需要拿到發送方使用的密鑰；如果不能保證密鑰傳遞是可靠且隱秘的，就沒什麼安全性可言。可如何安全地傳遞密鑰呢？這實際上與建立「加密信道」的過程基本一致。

謝邀。

區別還是非常大。
首先你要明白https到底是怎樣的協議，以及它為什麼要這麼設計。
給你搜了一篇講解https原理很好的文章。
https://cattail.me/tech/2015/11/30/how-https-works.html
還可以參考wikipedia。

下面換一種方式來講。
假設沒有https，而你要用http進行可信並且保密的通信，你要怎麼做？

首先最簡單的就是用js加密數據。
過程主要是：瀏覽器在js中加密數據；傳給伺服器；伺服器接收數據；伺服器解密；伺服器返回加密的數據；瀏覽器接收數據；瀏覽器解密。這樣完成一次通信。
顯然用對稱加密在這是不靠譜的。瀏覽器要解密你的數據需要你加密用的秘鑰，而只可能是瀏覽器告訴伺服器秘鑰，這樣，中間人很容就得知了秘鑰，毫無安全可言。

為了避免這個問題，可以採用一種秘鑰協商演算法（比如DH），這樣即便中間人獲取了雙方的通信，也沒辦法知道你的秘鑰。不過即便這樣，還是無法防範中間人攻擊。如果中間人不但能獲取通信，還能介入，就可以將自己偽造成伺服器與瀏覽器通信，而對於真正的瀏覽器這偽裝成瀏覽器，這樣，中間人參與了秘鑰協商的過程，那麼知道秘鑰，知道整個通信內容。

好，換一個思路，用公鑰加密，這樣就不需要傳遞秘鑰了。
瀏覽器用伺服器的公鑰加密數據，並將自己的公鑰加密給伺服器；伺服器用自己的私鑰解密，返回的數據用瀏覽器的公鑰加密；瀏覽器收到數據用自己的私鑰解密。完成一次通信。
即使這樣，也是不安全的。因為瀏覽器不可能存儲所有伺服器的公鑰，所以只能是以某種途徑獲取。中間人也能獲取到這個公鑰，中間人可以欺騙瀏覽器，以自己的公鑰替換伺服器的公鑰，這樣就能偽裝成伺服器與瀏覽器進行通信，並且劫持雙方的通信。

可以看出，重點是可信的問題。不過沒關係，我們可以加入證書認證系統，這樣就能確認雙方的身份，避免中間人攻擊。然後用前面提到的方式加密數據，然後再處理一些諸如加密演算法選擇，消息完整性檢驗等等，這樣的通信基本上就安全了。不過這差不多就是講https重新「發明」了一遍。

http是一點安全性都沒有。
https，協議本身是安全的。但是使用https的通信不一定。造成不安全的原因主要有：
1、使用了不安全的證書。
2、使用了不安全的加密演算法。
3、有缺陷的實現方式。
4、系統或者軟體漏洞。

以下結論僅針對被傳輸數據的保密性（confidentiality of payload）。

如果有可靠渠道分配接收方公鑰的話，的確可以用http做承載協議來傳輸加密後的信息，並且可以保證傳輸信息的安全性。PGP就是一個例子。

這個問題跟密碼學本身有關

先看一個很通俗的例子

需求：

有三個人

張三：他有一封要給李四的私密信件

李四：他要收到張三給他的私密信件

隔壁老王：邪惡的快遞員叔叔。

方案1：

張三和李四約好在某一天一起去買了一個帶鎖的盒子，配了兩把鑰匙，一人一把。

張三把信放到盒子里，上鎖，快遞老王把盒子快遞給李四，李四用自己的鑰匙開鎖，拿到信件。

但是有個問題：如果張三李四無法一起約好去買盒子怎麼辦。

方案2：

李四去買了一個帶鎖的盒子，把鎖打開，把這個盒子給快遞老王，張三收到盒子後，把信放到盒子里，上鎖。

快遞把上鎖盒子送到李四手上，李四用鑰匙解鎖，拿到信件。

區別，

前者通信兩個人需要同一把鑰匙。 —— 對稱加密

後者通信兩個人可以選擇不同的鑰匙，（想像一下，張三李四各有一個盒子，一把鎖及其鑰匙，鎖可以掛在盒子上，但沒有鎖死......） —— 非對稱加密（盒子就是傳說中的公鑰，鑰匙是傳說中的私鑰）。

任何一種信息傳輸都面臨兩個要解決的問題：1：連接建立， 2：數據傳輸。

在網路場景下加密演算法在速度上一個普遍的規律是對稱加密 &>&> 非對稱加密，原因有2：

1. 方案1中快遞老王一次通信只要運送一次帶信的盒子即可，方案2中快遞老王先要運空盒子，再要運帶信的盒子， I/O次數有差異

2. 從演算法本身的設計來說，非對稱加密演算法的複雜度也要比對稱加密演算法複雜的多。

所以對於數據傳輸（相對建立連接階段傳輸的數據來說，屬於大量數據），要使用類似方案1的方法，做對稱加密。

而對稱加密的鑰匙面臨著之前提出的一個問題：如果張三李四無法一起約好去買盒子怎麼辦？所以這個鑰匙需要在建立連接的階段協商好，怎麼辦？答：方案二中提到的非對稱加密。

這就是HTTPS在安全性上最核心的思想 —— 使用非對稱加密做連接建立，使用對稱加密做數據傳輸。

因為HTTP連接本身明文的，所以我理解所謂的HTTP加密是基於秘鑰簽名機制去做的。

至於HTTP上做加密邏輯，由於HTTP本身是明文傳輸，並且沒有建立連接階段的加密機制，在攻擊者角度來看就顯得漏洞百出了。

比如說：

客戶端的秘鑰真的安全嗎？被逆向了怎麼辦？換個秘鑰？那麼其他成百上千的客戶端怎麼辦？簽名演算法能夠做的有多複雜？會超過現有的AES的複雜度嗎？簽名演算法能夠抵擋當代計算機的計算速度嗎？......

所以我想說的是在HTTP場景下不要談加密，加密場景永遠存在三個角色，信息發送者，信息接收者，信息監聽者，並且這個信息監聽者計算能力特別特別的牛逼。

以上是用很通俗的語言去講密碼學。

相關專業知識可以參考：openssl, 對稱加密與非對稱加密, 秘鑰交換，典型流行的加密演算法包括： RSA, AES, 橢圓曲線加密演算法，迪菲赫爾曼秘鑰交換等。

想補充幾點：

1. 一直所說的HTTPS比HTTP慢，其核心也是在加密演算法上的表現。但當前已經有很多建立連接階段的加速方案，所以，當前來說，HTTPS比HTTP慢，只能說慢的沒那麼明顯了。

2. HTTPS 本身也是對 HTTP 的升級版本，本質上他們都是超文本傳輸協議，把HTTP設計上各種加密場景都考慮了，那就是HTTPS了。

HTTP雖然能使用JavaScript等方式加密數據，但是不能驗證通訊雙方的身份，如果HTTP遇到了中間人攻擊，攻擊者可以攔截通訊雙方的通話並插入新的內容。如果被劫持了DNS和網頁內容，你可能會打開一個假的網站。HTTPS可以防止以上情況的發生。

一個是只在放錢的地方上鎖，一個是讓你的整棟房子加上防護，還讓你知道是不是約對了人。

高票答案根本就是直覺回答，壓根沒動腦子。
這不是一個完全重複的輪子。
https只保證了鏈路的數據安全，但是數據在終端解密之後，使用瀏覽器提供的介面，也不需要特別高的許可權，就可以輕而易舉的把明文讀取出來了，例如chrome plugin
而用http加密，在保障鏈路安全的同時，也讓終端上讀取數據沒那麼容易，至少不再是通用的介面，甚至黑客更高的許可權來讀取瀏覽器的進程的內存，而且依舊沒有通用的方案。

如果你指的加密是對稱密鑰加密，那麼有兩個問題，人多的情況下，第一密鑰分發困難，第二密鑰數量爆炸

如果你指得加密是非對稱加密，那麼要麼你在應用層重造了一個https輪子，要麼你的加密有安全漏洞

還有你用https的話，別人監聽你的流量，只能看到一個加密通信連接，是不知道你在用https的，而你用http+加密，別人至少知道你在用http

不是可比的東西。

HTTPS: 為了保證傳輸安全，數據在傳輸過程不被篡改；
你文中的http加密: 不知道只是md5之類的hash還是js對稱加密，但願題主了解base64編碼與解碼。首先，如果是md5之類的hash，個人覺得其實用處不大，可以模擬；其次，js實現的對稱加密，其實並不具備很強保密性，畢竟前端代碼一覽無餘，只是混淆等讓分析更困難些。

=======
手機碼字有點累
以上純屬個人理解，歡迎指正。

作為一個銀行收單系統的開發者我想說，HTTP協議加密報文體的方式可控性更高點。另外使用HTTP協議的客戶端也不只有瀏覽器，大部分的app也是用的HTTP協議。
首先HTTPS能保證鏈路安全的說法這是片面的，只能說在瀏覽器環境下，相對是安全的，畢竟通過偽造證書代理等方式還是很容易篡改報文的，單純的HTTPS以下幾個問題暫時還是無法解決的；
(1)證書如何更新，正常情況更新的頻率是很高的，這是保證無法被暴力破解，正常情況是要求幾天一次更新甚至一天更新一次。
(2)如何做到同一個介面使用不同的密鑰，對於pos機來說，讓全部的終端共用一樣的通信密鑰，這種做法是非常不安全的。

基於以上兩點，我們其實比較推薦的做法是使用HTTP協議，然後再報文體中實現雙向的SSL認證，密鑰由後台分發。
至於防篡改有兩種實現方式：
(1)雙向SSL中增加簽名機制。
(2)使用對稱密鑰的Mac校驗。

最後總結下，在實際使用中，我們往往是多種手段配合使用的；另外使用HTTP的協議加密報文體，這個加密過程肯定是不能使用自研演算法的，當然你可以用現在傳說中的國密演算法。

https有大把的硬體off load加速解決方案，你那個有哇？

我覺得必須要補充一點:

信息安全上不自己造輪子的一個重要原因是:

一個理論上安全的演算法，即使自己正確實現了，也幾乎肯定是不安全的。

比如 Timing Attack, 你實現了一個運算結果正確的 AES，但攻擊者可能可以通過演算法運算時間的微小區別獲取一些信息，從而大大減少攻擊所需要的時間。即使你在編寫代碼的時候注意到了，編譯器優化和不同編譯器之間的區別也有可能再次使問題暴露。比如橢圓曲線中用到的 binary exponentiation 類似的演算法，RSA 所用到的模冪運算，都有可能被運用這種攻擊。

以上只是一個例子，還有許多精密的，針對實現本身的攻擊手段，一開始是不可能考慮完全的，更何況嘗試自己實現一整個密碼套件來替代 TLS 協議。

通用的密碼學庫，都是經過多年考驗不斷改進而來，而自己設計 / 自己實現的演算法在專業攻擊者面前，通常都是不堪一擊。

最主要的區別就是用 HTTPS 的時候可以驗證內容提供方的身份，而 HTTP 不可以。

使用 HTTPS 的時候，客戶端首先會驗證內容提供方的身份，然後再傳輸數據。如果經過驗證後發現內容提供方提供的證書不正確，客戶端會阻止用戶連接到該內容提供方。

而用 HTTP 的時候則缺少這一步驗證。用戶在請求數據的時候，有可能被重定向至一個假內容提供方，這樣用戶根本就不是連接到你的伺服器，因此就無從談起用 HTTP 進行數據加密了。