1樓：安信SSL證書
HTTP：是網際網路上應用最為廣泛的一種網路協議，是乙個客戶端和伺服器端請求和應答的標準（TCP），用於從WWW伺服器傳輸超文字到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網路傳輸減少。
HTTPS：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。
HTTP和HTTPS區別 HTTPS的好處二、HTTP和HTTPS的區別（2）HTTPS需要用到SSL證書，而HTTP不用;
（3）HTTPS標準埠443，HTTP標準埠80;
（4）HTTPS基於傳輸層，HTTP基於應用層;
（5）HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;
2樓：少敦
HTTP 是應用層上的純文字協議，就是說，從傳輸層 socket 拿到位元組再將它們轉換成字串之後看到的內容就是另一端發給你的內容，毫無秘密可言。如果有人在傳輸過程中的某個節點劫持傳輸的資料，就能完完全全地讀取到 Client 與 Server 之間傳輸的內容，你傳的是使用者名稱和密碼，那就悲劇了。
為了避免這種悲劇發生，就有了 HTTPS，S 代表 SSL，也可以是 TLS，可以將 TLS 理解為 SSL 3.1 版本。
HTTPS 主要解決了兩個問題，
加密：如何防止通訊內容被直接讀取
信任：如何確認正在通訊的伺服器就是想要通訊的伺服器
先說加密，為了不讓別人看到傳送的文字，就需要先對文字進行加密，加密一般有兩種方式，對稱加密和非對稱加密。對稱加密只需要乙個金鑰，通訊雙方都用同乙個金鑰進行加密和解密；非對稱加密需要乙個金鑰對，公鑰和私鑰對，由通訊的一方（伺服器）建立，保留私鑰，將公鑰發給另一方（客戶端）。凡是用公鑰加密過的資訊，只能由私鑰進行解密。
你自然會想到，只要在發起 HTTP 請求前，先從伺服器拿到公鑰，然後將 HTTP 內容用公鑰加密後傳送給伺服器就可以保證不會被別人讀到。加密過的內容確實只能由伺服器的私鑰解密過後才能讀取到。
但是還有一種情況，在請求公鑰的過程中，有壞人在中間假扮真正的伺服器，發給你自己的公鑰，之後再一直跟你通訊，那你傳送的內容都被壞人看到了。這就引出了如何驗證伺服器的身份問題。為了解決這個問題，人們整了乙個可信的第三方，叫做 CA，由它來協助驗證伺服器。
伺服器向 CA 提供伺服器的資訊，CA 會生成乙個金鑰對（公鑰和私鑰）以及乙個證書，其中公鑰是證書的一部分。CA 還會對證書進行數字簽名，這個數字簽名是將證書經過一次雜湊函式後用 CA 的私鑰加密後的加密文字。客戶端每次跟伺服器通訊時，伺服器先把帶有數字簽名的證書發給客戶端，客戶端用 CA 公開的公鑰對數字簽名進行解密，得到的雜湊值與證書的雜湊值進行比較，兩個值相同，說明身份是真實的，這樣客戶端就拿到了真實的伺服器公鑰。
但事實上，HTTP 文字是用對稱加密演算法加密，原因是
非對稱加密比較慢
非對稱加密對文字長度有限制
那之前費很大勁兒拿到的公鑰有什麼用呢？它是用來加密傳輸對稱加密使用的金鑰。
3樓：
那時候我們專業的密碼學課程剛剛過半。
那時還處於WEB2.0時代，我給一家學術機構發過一篇文章，大意是通過密碼技術，對使用者登入過程中的敏感資訊進行保護的機制，也經過反覆多次的推敲。
過段時間收到機構的Email回覆，很禮貌的告訴我說我寫的東西就是PKI，不具備創新性。
4樓：evendu
是不是用了HTTPS，傳輸的協議資料就不需要自己再去加密了呢？
使用了HTTS，對於要傳輸的資料再加密是不是就顯得多餘了？有沒有必要這樣？
5樓：
區別很大，https是全文加密，整個流量包抓包看就是普通的TCP協議流量，而你說的將以http協議將資料加密後再傳輸，實際上還是http協議的流量，這在抓包分析中還是能看到http包頭資訊。再加上你用的加密演算法，能和主流的RSA非對稱加密比嗎？安全性不是在乙個檔次。
如果你想要全文加密，對不起你必須遵從現今的瀏覽器支援的加密方式，不然你的網頁不會給你顯示，繞回來你還是必須用https協議才能達到全文加密。
6樓：用心閣
其實簡單的加密後通過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伺服器解密，要不由服務端程式解密，而後者增加了程式設計的複雜性。
7樓：
https保護了
1. 認證，雙方通訊是可信可證實體
2. 金鑰交換，金鑰是不會洩露的
3. 機密性
4. 完整性
5. 新鮮性
6. 完美前向安全
機密性只是其中的乙個保護，其他保護更重要
8樓：王泥煤
高票答案根本就是直覺回答，壓根沒動腦子。
這不是乙個完全重複的輪子。
https只保證了鏈路的資料安全，但是資料在終端解密之後，使用瀏覽器提供的介面，也不需要特別高的許可權，就可以輕而易舉的把明文讀取出來了，例如chrome plugin
而用http加密，在保障鏈路安全的同時，也讓終端上讀取資料沒那麼容易，至少不再是通用的介面，甚至黑客更高的許可權來讀取瀏覽器的程序的記憶體，而且依舊沒有通用的方案。
9樓：玄星
以下結論僅針對被傳輸資料的保密性（confidentiality of payload）。
如果有可靠渠道分配接收方公鑰的話，的確可以用http做承載協議來傳輸加密後的資訊，並且可以保證傳輸資訊的安全性。PGP就是乙個例子。
10樓：楊小小小小小明
https基本上可以理解為：在http協議的基礎上，增加了一套協商機制，這套協商機制用來協商https在通訊過程中用哪些加密套件來加密和解密。。。
11樓：
因為Https是全程加密的！
雖然有可能被降級可能！
但是https還是應對運營商劫持的最好辦法！
自己用http被劫持一點辦法沒有～
HTTPS最起碼有個可信任的根證書！
12樓：BeterHans
https 是乙個系統
http 傳輸加密資料當然沒啥問題，但是對方靠什麼來解密？ 你怎麼告訴對方用什麼鑰匙解密？ 不能解密的資料有何意義？
13樓：Karl
TLS的作用是資料防洩漏資料防篡改身份識別。
你說加密的HTTP，最多也就能完成他的第一項功能。如何防止重發包攻擊，如何防止中間人攻擊？
等你的加密協議能完整的做到這三項了。我估計你這協議和TLS也差不多了。那你為什麼不用相容性更好的TLS呢。
14樓：純純
核心問題不在於要不要自己造輪子之類的。。
你自己在頁面裡做加密解密，中間人直接在你的頁面第一次被訪問的時候直接截獲替換乙個fake的頁面騙使用者的保密資訊，要怎麼防止呢？
15樓：SuperFashi
一般我都是https套一層https，aes以特殊的方式藏在header裡，要不是逆向dalao普通人還是很難搞出來的。
16樓：
HTTP能被網路運營商以各種姿勢劫持，插乙個js就可以悄無聲息地偷走密碼，在這種情況下用js搞一遍DH+AES沒有意義。
如果攻擊者不能劫持篡改，只能竊聽，那用js加密一下可以防止明文密碼暴露，但疏忽大意就會允許重放攻擊。
17樓：右值引用
最主要的區別就是用 HTTPS 的時候可以驗證內容提供方的身份，而 HTTP 不可以。
使用 HTTPS 的時候，客戶端首先會驗證內容提供方的身份，然後再傳輸資料。如果經過驗證後發現內容提供方提供的證書不正確，客戶端會阻止使用者連線到該內容提供方。
而用 HTTP 的時候則缺少這一步驗證。使用者在請求資料的時候，有可能被重定向至乙個假內容提供方，這樣使用者根本就不是連線到你的伺服器，因此就無從談起用 HTTP 進行資料加密了。
18樓：雲舒
將資料加密然後http傳輸，當然可以。當你把安全性的各種問題都考慮完善並且實現了，那麼恭喜你，你把https協議做出來了。
19樓：宇文黎琴
你說的只是一種情況
通訊使用明文，內容可能會被竊聽。
但是，即使是加密的訊息也有可能會被窺視。
沒有驗證對方的身份，有可能遭遇偽裝。也無法驗證報文的完整，沒辦法知道是否被篡改。
20樓：
從原理上來說，題目的觀點沒錯，「加密內容在公開信道傳輸」並不比「未加密內容在加密通道傳輸」更不安全；但是，在實際應用中，還是有不同的：前一種方式下，接收方要解密內容，就需要拿到傳送方使用的金鑰；如果不能保證金鑰傳遞是可靠且隱秘的，就沒什麼安全性可言。可如何安全地傳遞金鑰呢？
這實際上與建立「加密通道」的過程基本一致。
21樓：exiledkingcc
還可以參考wikipedia。
下面換一種方式來講。
假設沒有https，而你要用http進行可信並且保密的通訊，你要怎麼做？
首先最簡單的就是用js加密資料。
過程主要是：瀏覽器在js中加密資料；傳給伺服器；伺服器接收資料；伺服器解密；伺服器返回加密的資料；瀏覽器接收資料；瀏覽器解密。這樣完成一次通訊。
顯然用對稱加密在這是不靠譜的。瀏覽器要解密你的資料需要你加密用的秘鑰，而只可能是瀏覽器告訴伺服器秘鑰，這樣，中間人很容就得知了秘鑰，毫無安全可言。
為了避免這個問題，可以採用一種秘鑰協商演算法（比如DH），這樣即便中間人獲取了雙方的通訊，也沒辦法知道你的秘鑰。不過即便這樣，還是無法防範中間人攻擊。如果中間人不但能獲取通訊，還能介入，就可以將自己偽造成伺服器與瀏覽器通訊，而對於真正的瀏覽器這偽裝成瀏覽器，這樣，中間人參與了秘鑰協商的過程，那麼知道秘鑰，知道整個通訊內容。
好，換乙個思路，用公鑰加密，這樣就不需要傳遞秘鑰了。
瀏覽器用伺服器的公鑰加密資料，並將自己的公鑰加密給伺服器；伺服器用自己的私鑰解密，返回的資料用瀏覽器的公鑰加密；瀏覽器收到資料用自己的私鑰解密。完成一次通訊。
即使這樣，也是不安全的。因為瀏覽器不可能儲存所有伺服器的公鑰，所以只能是以某種途徑獲取。中間人也能獲取到這個公鑰，中間人可以欺騙瀏覽器，以自己的公鑰替換伺服器的公鑰，這樣就能偽裝成伺服器與瀏覽器進行通訊，並且劫持雙方的通訊。
可以看出，重點是可信的問題。不過沒關係，我們可以加入證書認證系統，這樣就能確認雙方的身份，避免中間人攻擊。然後用前面提到的方式加密資料，然後再處理一些諸如加密演算法選擇，訊息完整性檢驗等等，這樣的通訊基本上就安全了。
不過這差不多就是講https重新「發明」了一遍。
http是一點安全性都沒有。
https，協議本身是安全的。但是使用https的通訊不一定。造成不安全的原因主要有：
1、使用了不安全的證書。
2、使用了不安全的加密演算法。
3、有缺陷的實現方式。
4、系統或者軟體漏洞。
http 是指什麼意思，http 和 https 之間有哪些區別？
葫蘆娃集團 HTTP是乙個優秀的通訊協議，不過事物皆具有雙面性，該協議也是有不足之處，大概有以下幾點 使用明文傳輸，可能會被竊取不安全 不驗證通訊方身份 無法證明報文的完整性，證明不了報文是否被修改 HTTPS協議則提供了較為完善的方案。HTTPS不是一種新協議，是通過HTTP結合SSL TSL實現...
用統計理解資料，和用機器學習理解資料，哪個更靠譜？哪個更有前途？
張俊紅 首先可能需要拉齊一下大家對於 理解資料 中 理解 這一詞的認知，我覺得這裡的 理解 可以等同於 分析 那變換下這個問題就是 分析資料，用統計方法好還是用機器學習更好？先說結論 好的分析是分析中統計和機器學習都會用到，都需要好好學。所以這個問題可能也就不必要存在了。如果非要在兩者中間選乙個的話...
資料庫能做搜尋嗎？用資料庫做搜尋的優點和缺點有哪些？
陳廣勝 在網際網路早期，LAMP剛開始大紅大紫的那個時代，許多站點的搜尋就是用資料庫的做的。就是簡單地在要搜尋的字段上加個倒排索引。這麼做的優點是維護和開發簡單，了解點SQL就可以了。不過隨著資料量越來越大，這種做法顯得不是那麼高效。搜尋對於大多數應用來說，不太需要關係型資料庫的一些功能，如事務處理...