不用 https 自己實現對 http請求的內容的 rsa 加密，這樣足夠安全嗎？

12-29

設想的方案如下：
服務端生成一對 RSA 的公鑰和私鑰，在前端第一次請求的時候，將公鑰返回給前端。

前端保存這個公鑰，每次向服務端發起請求的時候，請求的內容體使用這個公鑰加密。

並且前端在發起請求前，也生成一對 RSA 公私鑰，請求內容附上公鑰，這樣服務端返回的內容就可以用這個公鑰加密了。（單頁面應用，秘鑰都是2048位的）

（可能防篡改、防重放還有些問題，但是再加上驗證的步驟應該也能實現。）

如此，不使用 https，直接在http的之上做這樣一套，這樣能實現 https 一樣的安全程度嗎？

你這種方法直接用一個中間人攻擊就完了。
A發信息給B，C在中間拿到A傳來的「公鑰A」，並將「公鑰C」發送給B，B將信息打包好後用「公鑰C」加密並發送，C拿到信息後用「私鑰C」解密，將想要篡改的信息修改後再用「公鑰A」加密發送給A，就能按照C的意願來執行一些操作了。

1.你可以自己用http，甚至js、Java、C++、PHP來實現rsa。

2.但你的問題描述中的那套方案不行，因為這不符合規矩。你就算要自己造輪子，也得按照規矩來搞，建議還是讀讀書，看看標準流程是怎麼做的。

有的答主說【這個問題下回答「能」，「不建議」的都是信息安全沒學好的-_-#】，我想說你xian 模擬RSA整套系統的源碼，包含CA、CertificateChain、Server、Client、Hacker、ProxyDebugger，當年我的導師靠我這套系統....唉不說了，國內這高校環境...

不用https的話，任何人都能「偽裝」你的身份，傳輸」加密了的假的數據「。因為第一次登錄你的網站的人不知道你的公鑰是什麼，你又沒有證書，所以沒有辦法證明「你是你」。

可以的。缺點是你需要專用的瀏覽器和http server
為了推廣你需要定義一套規則和技術實現的框架和指導。為了這個協議被廣泛支持採用你需要提交你的協議提案給標準化組織，形成行業標準。

而這一切https已經在幾十年前已經做完了。所以為什麼要重複發明輪子？

這個問題下回答「能」，「不建議」的都是信息安全沒學好的-_-#

先不說@雲舒提到的公鑰分發的問題?加解密的演算法你要怎麼分發到客戶端？

從理論上看可以，但無法保證安全。
伺服器端存有私鑰(Private Key)和公鑰(Public Key)，但只公開公鑰
一般使用HTTPS(SSL/TLS)連接的過程是:

客戶端獲取伺服器端公開的公鑰

客戶端通過AES等對稱加密生成一個密鑰，並使用伺服器的公鑰非對稱加密(PGP)成為密文後發送給伺服器

客戶端使用生成的AES密鑰加密數據，發送密文給伺服器

伺服器將收到的，被非對稱加密的AES密鑰使用RSA等非對稱加密私鑰進行解密.得到AES密鑰的明文

伺服器端以此(明文AES密鑰)解密客戶端發送的密文數據，也使用這個密鑰加密數據發送給客戶端.

由此看，HTTPS的通信過程中加密數據使用的是對稱加密，而不是RSA等非對稱加密，非對稱加密僅用於傳輸對稱加密的密鑰，讓伺服器、客戶端雙方都知曉對稱加密密鑰。

而如果遇到中間人攻擊(MITM,Man-in-the-middle)呢，在SSL連接中客戶端可以向權威的CA來驗證伺服器提供的公鑰是否被替換，但樓主的方案無法驗證公鑰的可靠性。
如此一來:

中間人得到伺服器公鑰

中間人生成一對公鑰和私鑰(稱作"公鑰2"和"私鑰2")

中間人將公鑰2發送到客戶端

客戶端無法分辨真正的公鑰和"公鑰2"，使用公鑰2將AES密鑰加密，發送出去經過中間人

中間人使用私鑰2將AES密鑰解密，再用伺服器公鑰加密發給伺服器

你的(使用AES加密的)密文數據也經過中間人，而此時中間人已得到明文AES密鑰

數據被中間人解密。而伺服器和客戶端都不知道泄密已經發生。

但是在一種情況下樓主的方案也能做到安全:通過絕對可靠的途徑(e.g. 線下)傳遞公鑰。

前面各位專家都已經說了HTTPS/題主的各個方面了，我來補充一下
問題依次是：信息要加密----加密密鑰要加密----要確定第二個加密密鑰是來自於真的伺服器

1.RSA本身只是加密對稱加密的密鑰的；為了保證傳輸速度，用rsa公鑰私鑰技術傳遞對稱加密密鑰。信息本身用對稱密鑰加密。（一定的包數後重新更新一次對稱加密密鑰）

2.RSA的方法就是客戶側傳給伺服器的信息；伺服器用私鑰解密，客戶端用公鑰加密，反之亦然。

3.中間人攻擊的前提條件是客戶無法鑒定中間人和伺服器端的差別。為了解決這個問題，DSA演算法用於向客戶證明自己是真伺服器（即數字簽名技術）---利用客戶電腦內置的CA證書的公鑰來解密伺服器端的用私鑰加密的簽名。中間人一般無法獲取到伺服器的私鑰（與RSA剛好相反）

------------------------------------以上過程的前提條件是用戶/伺服器均未被黑，且均做了完整的校驗過程，攻擊者只能在網路層面進行攻擊-------------

1.如果伺服器/PC被黑，自然就完蛋了；

2.如果PC瀏覽器提示：您連接到了一個不安全的https，然而依舊連接，自然就完蛋了

3.手機APP上，部分用了HTTPS的APP，依舊可以用代理方式中間人解開，說明這些APP的CA校驗應該是信任了手機本地的CA庫。所以也是較易被黑的；不過這招對大taobao好像是沒用的。。。taobao應該是沒有信任手機端的CA證書

4.SSL和TLS如果被黑了，那也玩完。。例如心臟滴血

https的安全性除了加密通信，還有重要的一點是服務認證，你的方案沒法確認這個伺服器就是你要請求的域名，被劫持了你也發現不了

曾經有一個人，想法跟你一樣，在http上做加密，
最後完成任務，交給老闆。老闆說，這是你做的，你有一個特權，給這個東西取個名字，叫什麼？
這個人想了三天，命名之，https

不能，不能，不能，重要的事情說三遍。
首先HTTPS的每一步都已經在「保證」安全的前提下做了最簡化。SSL握手完成了對伺服器的身份驗證和雙方秘鑰的協商：驗證伺服器證書，用證書里的公鑰加密傳輸秘鑰素材。你的過程沒法完成這兩個功能，安全也就無從談起。
另外RSA2048私鑰解密操作時非常慢的（RSA2048公鑰加密操作相對快很多），這會讓通信雙方不堪重負，性能會像蝸牛一樣慢。

槽點太多無法按順序說了………少年你對https的理解還差的遠，才剛剛理解非對稱，對pki體系算是一無所知了。
你這最大的漏洞是客戶端無法驗證服務端合法性，https由多級ca簽名和客戶端內置根證書來保證服務端合法性。保證不了服務端合法性會被中間人攻擊，dns劫持釣魚妥妥的。
要改的話有幾個辦法
1、通過其他渠道下發公鑰，比如寫個瀏覽器代碼里內置公鑰，這樣你可以省去https的第一次握手，但是光這樣你還是不知道它是不是真的服務端，你可以要求服務端使用你發過去的公鑰加密一個指定內容比如『我是真的服務端你一定要信我2016年5月1日0點5分25秒』並返回
2、通過其他渠道下發對公鑰簽名的公鑰╮(╯▽╰)╭，說人話就是內置根證書，用這個公鑰對應的私鑰對服務端下發的公鑰簽名

https安全的地方在於ca這個東西的存在，而不是你用什麼加密，沒有ca中間人公里連偽造證書都不用了，更省心

不可以，第一次通訊前將公鑰發送到客戶端那裡是不可信的。https的的解決方案是在瀏覽器中預設一個證書列表，而如果你實現的話我覺得夠嗆

題主想自己實現一個HTTPS，然後有人回答能實現，再然後有的答主說回答能實現的是信息安全沒學好的，嗯，搞HTTPS的人是信息安全沒學好的。

不能
第一要想獲得Https的方便性你還是要在web伺服器端和瀏覽器端實現你說的這個協議一般很難辦到如果不這樣那麼密鑰怎麼保存？
第二 Https之所以這麼設計就是因為非對稱加密比對稱加密消耗資源所以不只是安全性能方面就落了下風
第三通信安全主要有三方面正確性也就是雙方身份正確保密性還有完整性你這樣加密一下只能保證保密性而已別人修改了你還是不知道
Https這麼複雜是有它的道理的

因為這個加密只能確保雙方秘鑰交換之後的傳輸的加密，並不能確保雙方的身份，所以可能出現中間人攻擊。總之是雙方都無法確認對方的身份，不能認證任何一方的真實性。
可以考慮加入自定義加密演算法（容易被打哈，不要太輕易嘗試），或者可以考慮提前共享秘鑰，或者是進行單向認證之類的辦法都可以的。

Https協議最重要的一步就是最開始建立的信任。以後的密鑰，以及其他信息的交換都基於最開始的信任。那麼最開始的信任是怎麼建立的呢。客戶端向伺服器發起請求後，伺服器會傳給客戶端一個證書，然後客戶端會根據本地根證書驗證客戶端證書的合法性，包括證書有效時間，證書綁定的域名和訪問的域名對比等等，如果通過，則用證書中的公鑰加密客戶端生成的對稱密鑰並傳送給服務端。注意！用證書中的公鑰很關鍵，這樣就可以防止信心被中間人劫持，發給你一個假的公鑰。因為證書和域名綁定，所以無法偽造。這樣只要證書驗證通過，以後的通話就可以安全的進行。而你所說的客戶端和服務端交換彼此的非對稱密鑰進行加密，無法保證你收到的密鑰一定是客戶端的，建立在密鑰安全性無法保證的前提的通信當然是不安全的。

可以，不過可能需要做一個額外工作。

將客戶端公鑰列印在紙上，派特工，利用死間計劃將公鑰安全地送往伺服器機房並上傳，然後再把伺服器的公鑰列印出來帶回，導入客戶端。

等你了解完全套內容，大概就會放棄這個想法了…

如果你把你的所有過程都用你自己的演算法實現的話而且都進行加密的話我估計是相對安全的。使用別人包裝好的東西你覺得會很安全嗎？？