1樓：徐辰
其實你大可以在http上面實現乙個類似ssl的協議，無非就是疊床架屋罷了。
最簡單的方式就是預共享金鑰，通過這個金鑰交換會話金鑰，用會話金鑰加密每個請求和響應。如果你不是特別在乎安全性，連會話金鑰都可以省掉，直接用主秘密加密通道也不是不可以，但原則是用得越多的金鑰安全性就越低。
要想防止中間人重放攻擊的話可以撒一把鹽，每次加密前把內容用這把鹽預處理一下比如做個異或啥的就行。
2樓：yaoyao
簡單，利用資訊不對稱。混江湖的老早就知道用「切口」來驗證身份了。
第一步，你先和服務端要乙個一次性的切口，或者自己生成乙個，登入時一起傳給服務端
第二步，你用切口當鹽來計算密碼的摘要
第三步，服務端同樣用切口當鹽來計算密碼的摘要第四步，判斷一下兩個摘要是否相同，相同就是密碼正確。
別人知道切口但不知道密碼，所以沒法給出正確的密碼的摘要資料。即使截獲了這次密碼摘要資料，除了使用彩虹表，也不能逆向出密碼。因為切口是一次性的，所以重放也沒用。
3樓：不知道是誰
有乙個防盜取的想法.即前端傳輸（密碼+時間戳）的hash，以及時間戳。伺服器根據已知密碼和報文中時間戳進行同樣hash後比對。要求時間戳僅一次可用。
----不一定是時間戳。服務端保證一次可用就行。
4樓：saturnman
因為協議的共識的原因，http是不可能完全實現https的所有功能的。拋開協議的問題，http和https最核心的不可替代性在於CA的存在，CA的核心可以保證通訊物件的身份認證問題，至於https提供的其它功能是可以自己脫離CA自己實現的。
但是雖然自己實現一套能比較好保護使用者資訊的機制當然是可能的，就像TCP/UDP層一樣，自己做也可以實現比較好的安全性，因為沒有CA的存在會有一些理論上無法解決的問題所以在這裡安全性上要打乙個折扣，或是有一些假設的安全性前提條件。
條件2：除第一次信任機制外，必須在接下來的通訊中使用第一次協商好的證書而不可以脫離這個限制。
5樓：
假定要保護的是登陸密碼
思路是加密，這個其實方法比較多
最簡單的就是前端把密碼做個md5，再傳送到後台
當然密碼驗證是可以不用密碼明文的，如果需要還原密碼明文資訊，可以用自定義的密碼輸入框元件，密碼的加密由這個元件完成，比較靈活，可以隱藏加密演算法和金鑰
進一步要防重放，簡單說就是攻擊者擷取到密碼的密文以後，用這個密文多次重複請求登入介面會失敗
這個方法也比較多，比如在請求引數裡設定個隨機數，該隨機數和密碼一起進行md5運算後傳送到後台，後台快取住這個隨機數，只有第一次接收到隨機數時請求才是合法的，否則請求非法
如果是用自定義的輸入框，其實用唯一隨機數也基本夠用了，用加密演算法把隨機數和密碼一起加密傳輸
當然，後台要判斷隨機數是否唯一成本相當高，實踐中我們一般是快取住最近一段時間（例如10分鐘）的隨機數，這樣攻擊者就算重放，每10分鐘才能得逞一次，攻擊效率很低，傷害不大可以接受
6樓：八里土人
唯一可行的方式，是伺服器端配置證書，雙方基於此證書交換秘密。具體方式如下：
客戶端發起認證請求，產生隨機數，使用隨機數和伺服器公鑰生成只有伺服器靠私鑰才可以生成的金鑰，用這個金鑰加密使用者名稱。將隨機數+密文發給伺服器。
伺服器根據隨機數和私鑰生成解密金鑰，解密密文部分。根據此使用者名稱找到客戶的認證憑據。
使用此金鑰保護，執行認證協議。
這種情況下，使用ECC證書比RSA證書要簡單得多。相當於執行乙個ECC-DH協議。注意，使用伺服器公鑰加密會話金鑰存在不安全性，建議使用ECC-DH。
雙方各自提供乙個隨機數給對方
客戶端需要將自己在伺服器的標識發給伺服器（可能被中間人看到使用者名稱）
基於對方隨機數，和預共享的金鑰，使用摘要演算法，生成校驗碼。
對方執行相同的過程，如果校驗碼相同，則認證通過。
使用KDF生成session金鑰
注意，如果使用者口令在伺服器端使用了加鹽雜湊方式保護，那麼伺服器端需要將鹽值告知客戶端，客戶端也須做相同的操作，生成兩端共有的，相同的「預共享金鑰PSK」。
對於前端js也可以被獲取的情況，只能使用安全硬體解決了，使用Ukey。當然，如果Ukey都有了，執行https應該不成問題吧。
7樓：b4639b72facfdd7c
https在不可信通道上實現認證加密（Authenticated Encryption）靠的是通過無條件信任CA來信任伺服器證書。如果你要達到這樣的效果的話，可以在客戶端提前內建服務端證書，或者提前內建對稱加密金鑰，然後用公鑰加密或者私鑰加密去做。比如客戶端準備乙個類似銀行的u盾的玩意，不同的是，我們需要他內建伺服器的公鑰，而銀行u盾內建的是客戶端的私鑰。
如果要嘗試像https那樣協商乙個金鑰出來，對不起，還是用tls吧。沒有無條件信任的CA，做不到協商乙個只有雙方知道的金鑰、且確認雙方身份。
8樓：Tracy Liang
防不住中間人就沒有辦法，無論前端是用什麼加密方式，攔截下來都沒用。
只要中間人拿不到完全相同的資訊的時候就可以保證安全。
動態加密可以一定程度緩解，或者走其他更安全的渠道的簡訊，或令牌動態密碼，認證的手機掃碼。
9樓：浪狼郎
常規來看，應該沒啥辦法。如果有辦法，也用不著https了。
當然站在面試的角度，這麼回答未免太簡單了，我們得想想面試官想問什麼。
我們先看看要滿足安全，得達成哪些防禦
避免竊聽（知道你們在聊什麼）
避免篡改（就算我不知道你們在聊什麼，我也要改動某些資訊，讓你們溝通產生歧義）
避免中間人攻擊（不知道你們在聊什麼，但是我當傳話筒，卻傳遞著假的訊息）
避免重放攻擊（不知道你們在聊什麼，但是我一遍一遍重複某方的話）
https協議能達成以上1，2，3，4
關於https的細節，可以看這篇文章
浪狼郎：HTTPS到底有多複雜，能防止重放攻擊嗎？
https的主要流程如下：
客戶端和伺服器協商好對稱加密演算法、非對稱加密演算法、MAC演算法、不重數（nonce）；(完全明文）
客戶端得到了伺服器公鑰；（伺服器需要證明這個公鑰是伺服器的公鑰）
客戶端生成隨機的，僅僅針對這次連線的主金鑰（Master Secret），並用伺服器公鑰加密，傳輸給伺服器；
伺服器用伺服器私鑰對資訊解密，安全地得到了主金鑰（Master Secret）；（不會被竊聽，可能被修改，但被修改了客戶端就會無法解密）
雙方重新進行一次步驟1的通訊，但是用主金鑰（Master Secret）進行加密。
雙方使用主金鑰（Master Secret）對訊息進行對稱加密，並傳輸訊息。
因為非對稱加密計算量較大，整個通訊過程只會用到一次非對稱加密演算法（主要是用來傳輸客戶端生成的用於對稱加密的隨機數金鑰）。後續內容的加密解密都是通過一開始約定好的對稱加密演算法進行的。
有乙個小細節在於客戶端得到伺服器公鑰這裡。
伺服器公鑰的傳輸在原理上來說，明文也沒問題，但是擔心有人在中間當了伺服器中介差不多就下面這種情況，同時獲得了伺服器公鑰和客戶端金鑰。
對於客戶端來說，它需要確認這個公鑰是不是來自這個伺服器的，確定之後再給出自己的金鑰。這一步認證就交給乙個認證中心（CA）來完成。
認證中心簽發數字簽名
認證中心自己有一把私鑰和一把公鑰，每個遊覽器都會擁有各個認證中心的公鑰。
開發者需要向認證中心提交自己的網域名稱，認證中心先把伺服器的網域名稱、公鑰、證書有效期等資訊進行Hash，形成資訊摘要（不可逆向），再用自己的金鑰進行加密，形成數字簽名。因為數字簽名是由認證中心私鑰生成的，其他人都無法生成數字簽名，只能解析數字簽名。
2. 伺服器傳送數字證書
伺服器的網域名稱、公鑰、證書有效期等資訊+數字簽名=數字證書
3. 客戶端驗證數字證書
3.1 用認證中心的公鑰解密數字簽名得到資訊摘要
3.2 對伺服器的網域名稱、公鑰、證書有效期等資訊進行Hash，形成資訊摘要
3.3 對比兩個資訊摘要，如果一致，則說明這個公鑰確實來自我要訪問的伺服器。
中間人攻擊，可以修改明文的網域名稱、公鑰、證書有效期等資訊，但是生成不了資訊摘要，因此無法偽裝目標伺服器。
客戶端除了驗證資訊摘要，還要驗證數字證書中的網域名稱是否就是訪問的網域名稱、網域名稱是否過期等資訊。
看完了https的實現，大概也知道有限的加密怎麼做。也就是主流程那一套。但是在沒有認證中心（CA）的情況下，無法防止中間人攻擊。但是單說防止密碼洩露倒是夠用了。
那你可以聊的就多了。。。從攻擊的手段，到對應的防禦措施，一步一步告訴他http不可能實現完全的安全。
再提一點，就算是https，也不能防止CSRF攻擊
10樓：Anemone
好像很多大佬都在噴這套方案的證書問題啊，原先都想把這回答刪了，但是不知道怎麼刪，那只能看看能不能圓一下了，證書無非就是證明我是我的問題，其實都已經有點跑題了——我是指，建立了tls後的http登入請求不再受中間人攻擊，但是大佬卻執著於如何保證我一開始建立tls連線的伺服器就是真的伺服器這一問題。還有說雙向證書的，我都有雙向證書了，幹啥還要登陸啊，不會是要兩步驗證吧，還是現在我們還要跟親友同學公用一台電腦/手機的乙個系統賬戶啊，那我沒話說了。
首先最簡單的，目前主流系統裡面是有根證書的吧，可不可以重用這個證書？再者，我是說按著tls的路子，也沒必要100%按著tls的實現來啊，大不了用dh或者公私鑰在底層協議上把自簽名證書傳了唄（但是我又估計有人噴這個太麻煩了）？ tls方案經過那麼多年的完善，已經解決了很多潛在的坑，也有很多優點，為什麼不用呢？
再退一步說，沒有絕對的安全，我上面說那麼多，瀏覽器搞個uxss都得玩完，就算沒有，也沒人能百分百證明我是我這個問題啊。
回到面試，我認為把tls解釋清楚已經足夠回答面試官的問題了。
原回答：你按著tls的路子自己重新實現一套加密通訊唄
面試軟體測試，面試官經常會問，你對http協議的了解 這個問題應該怎麼回答比較準確。？
面試官 今天要不來聊聊HTTP吧？候選者 嗯，HTTP 協議 是客戶端和伺服器 互動 的一種通迅的格式 候選者 所謂的 協議 實際上就是雙方約定好的 格式 讓雙方都能看得懂的東西而已 候選者 所謂的互動實際上就是 請求 和 響應 面試官 那你知道HTTP各個版本之間的區別嗎？候選者 HTTP1.0預...
面試銷售面試官問如何看待銷售這個職業？
職場二十六畫生 從我個人的經驗來說，當我面試銷售時問這個問題，我可能是希望了解以下幾個資訊 1 面試者對於銷售這個工作的了解程度怎麼樣？2 面試者如何看待銷售這份工作，比如為什麼選擇，銷售相對其他工作有什麼利弊？3 面試者有哪些從業經驗，或者有哪些好的銷售特質？4 面試者在銷售這個職業方向有什麼獨到...
面試UI設計師，面試結束後向面試官問什麼問題好？
UEgood雪姐姐 可以問一下接下來團隊的工作重點和方向，或者就是你希望我來到後能著重哪些方向的設計。公司每年是否會提供學習機會 例如一些行業分享會，進修機會等 一家公司要招UI的話。基本要麼就是公司要開新專案，或者新產品線。或者就是老員工離職招你去填坑。或者就是公司裡的那個老Ul啊，他不勝任現在的...