在我的 Apache 服務(wù)器上，我使用 OpenSSL 創(chuàng)建了自簽名密鑰和證書對。我還將所有流量重定向為使用 HTTPS。在我的 C# 應(yīng)用程序上，我使用類似的方法來發(fā)送和接收數(shù)據(jù)。StringContent encodedContent = new StringContent(str, null, "application/x-www-form-urlencoded");client.PostAsync("https://myserverip/main.php", encodedContent)HttpResponseMessage response = client.PostAsync(URL, encodedContent).Result;除此之外，我還在服務(wù)器端和客戶端使用phpseclib實現(xiàn)了自己的 AES 加密。但所有這些加密和解密讓我很頭疼。我的問題是，我是否真的通過進(jìn)一步加密將通過 HTTPS 發(fā)送的數(shù)據(jù)來做出任何貢獻(xiàn)？
3 回答
慕桂英3389331
TA貢獻(xiàn)2036條經(jīng)驗 獲得超8個贊
這一切都取決于用例。對于傳輸安全性，TLS 通常被認(rèn)為足夠了?；〞r間保護(hù)該連接比添加額外的對策（例如消息特定加密）更好。
當(dāng)然，TLS 確實有局限性，因此可能需要額外的加密技術(shù)：
如果沒有顯式配置，TLS 不提供客戶端身份驗證；建立連接后可能必須執(zhí)行客戶端身份驗證。
從鳥瞰角度來看，它還僅提供點對點保護(hù) (*)；一旦 TLS 安全性被剝離，數(shù)據(jù)就不再受到保護(hù)。
同樣，您可能希望將數(shù)據(jù)安全地存儲在發(fā)送方或接收方。顯然 TLS 不會提供這樣的功能。
(*) 從 IP 協(xié)議的角度來看，TLS 提供端到端加密，因為 TCP/UDP 允許它在多個節(jié)點上路由（跳躍）受保護(hù)的 IP 數(shù)據(jù)包，但現(xiàn)在它經(jīng)常在到達(dá)目的地之前被剝離。應(yīng)用程序（TLS 卸載程序等）。
如果您已經(jīng)擁有共享密鑰，那么您可能需要查看 PSK 模式下的 TLS，但請注意該標(biāo)準(zhǔn)的實現(xiàn)并不像“常規(guī)”TLS 那樣常見。還要注意，您最多只能在兩方之間共享密鑰。
最后，僅通過使用 AES 加密消息來提供有意義的安全性的可能性微乎其微。您確實需要特定的用例、協(xié)議、方案以及最終的實現(xiàn)。通過“僅加密數(shù)據(jù)”來實現(xiàn)這一點的機(jī)會很小。這樣做的陷阱實在太多了。如果加密代碼或密鑰通過 TLS 連接（瀏覽器/JavaScript 加密）傳輸，則尤其如此。
呼如林
TA貢獻(xiàn)1798條經(jīng)驗 獲得超3個贊
這取決于您發(fā)送或接收的數(shù)據(jù)。在大多數(shù)情況下，HTTPS 為通過網(wǎng)絡(luò)發(fā)送的數(shù)據(jù)提供了很大的安全性，添加附加層只會使其變得多余，并且會占用處理時間。
慕田峪4524236
TA貢獻(xiàn)1875條經(jīng)驗 獲得超5個贊
我不確定您實際的問題是什么，因為您在標(biāo)題中提出的問題與文本中的內(nèi)容不同。
您標(biāo)題中的問題似乎是在詢問帶有自簽名證書的 HTTPS（= TLS）是否足夠，而不是“官方”證書。如果是這樣，那么是的，安全性方面沒有區(qū)別。不同之處在于，客戶端需要明確信任自簽名證書，而由大型根 CA（證書頒發(fā)機(jī)構(gòu)）之一頒發(fā)的證書將自動受信任，因為它們是隨操作系統(tǒng)一起交付和信任的。
然而，如果問題更多的是除了 HTTPS 之外是否還需要額外的加密，那么我的答案是：這取決于情況。
HTTPS（或 TLS）提供傳輸安全性，以防止數(shù)據(jù)在客戶端和（目標(biāo)）服務(wù)器之間傳輸時被看到。然而，兩端的數(shù)據(jù)都不會被加密。如果客戶端和服務(wù)器環(huán)境（文件系統(tǒng)等）可以被認(rèn)為是可信的，您不會提供信息。如果是這樣，HTTPs 應(yīng)該就足夠了。否則，建議對有效負(fù)載數(shù)據(jù)進(jìn)行額外加密。
- 3 回答
- 0 關(guān)注
- 194 瀏覽
添加回答
舉報
0/150
提交
取消