數字證書簽名、Lets Encrypt和證書劫持
現在安全體系中，最重要的一部分是數字安全加密體系，包括數字內容的加密解密，數字簽名和驗證。本文蟲蟲給大家介紹一下數字證書簽名以及世界最大的網站Https免費簽名Let's Encrypts，及數字證書簽名的安全性等問題。
概述
數字簽名就是在信息的后面再加上一段內容，可以證明信息沒有被修改過，怎么樣可以達到這個效果呢?一般是對信息做不可逆的哈希計算得到一個哈希值。在把信息發送出去時，把這個哈希值加密后做為一個簽名和信息一起發出去。接收方在收到信息后，會重新計算信息的哈希值，并和信息所附帶的哈希值(解密后)進行對比，如果一致，就說明信息的內容沒有被修改過。數字簽名在現在現代安全體系中非常重要基礎，可以用來確保文件的完整性、防止文件篡改以及身份認證等。首先我們說說幾個常見的數字證書基本概念：
RFC
RFC的意思是Request For Comments，中文對應為請求注釋，它是一堆描述不同協議的文本文件。如果想了解SSL，TLS(新的SSL)和x509證書(用于SSL和TLS的證書)如何工作，例如，想編寫自己的OpenSSL，則必須閱讀相應的TLS RFC。：的X509證書對應的rfc5280和TLS(1.2)對應的rfc5246。
x509
x509是為非正式的互聯網電子郵件，IPsec和WWW應用程序定義的證書規范，x509發展了三個版本，現在廣泛使用的RFC v3，其結構如下：
- Certificate ::= SEQUENCE {
- tbsCertificate TBSCertificate,
- signatureAlgorithm AlgorithmIdentifier,
- signatureValue BIT STRING }
這些是ASN.1結構。現代的證書就是這樣的：
- 第一個對象包含將要簽名的所有感興趣的內容，因此我們將其稱為"待簽名證書"
- 第二個對象包含CA用于對該證書簽名的簽名類型(例如：sha256)
- 最后一個對象不是對象，只是與DER編碼后的TBSCertificate 簽名相對應的一些位
ASN.1
它看起來很小，但是每個對象都有一定深度。
TBSCertificate是最大的TBSCertificate，包含一堆有關客戶端，CA，客戶端的公鑰等信息。
DER
當然不會像這樣發送證書。而使用DER將其編碼為二進制格式。
每個字段名都會被忽略，如果我們證書的形成方式，那么將不可能理解每個值的含義。
每個值都編碼為TLV三元組：[TAG，LENGTH，VALUE]
例如，查看Github的證書
右邊是DER編碼證書的十六進制轉儲，左邊是ASN.1格式的譯文。
如上面所見，如果沒有RFC，我們真的不知道每個值對應什么。openssl工具中自帶了很方面的命令行工具，可以用來解析證書的內容，簡單使用
openssl x509 -in cert.pem -noout -text即可
Let's Encrypt數字簽名
說到數字簽名就不能不對Let's Encrypt豎起大拇指，可以說它以一己之力為整個互聯網網站撐起了HTTPS的天。Let's Encrypt成立于2014年，是一家非盈利性的認證機構，目前為約2億個網站提供了數字證書認證，累積簽發了10億張的證書。
Let's Encrypt成功的關鍵取決于兩點：
(1) 它是免費的。Let's Encrypt之前，大多數證書頒發機構向要獲得證書的網站管理員收取費用。
Let's Encrypt證書和商業證書的區別：
(2) 它是自動化的。如果遵循其標準化協議，則可以通過API請求，續訂甚至吊銷證書。與此形成對比的是其他證書機構需要手動處理并需要一些時間來頒發證書。
如果網站管理員希望網站example-com(通過HTTPS)向用戶提供安全的連接，則可以向Let's Encrypt發出申請證書，并在證明自己擁有域example-com并頒發證書后，便可以使用該證書來與任何信任"Let's Encrypt"的瀏覽器協商安全連接。
這個實際流程如下：
- Alice使用RSA公鑰在Let's Encrypt中注冊。
- Alice要求Let's Encrypt證書example-com。
- Let's Encrypt讓Alice證明自己是example-com所有者，需要簽發一些數據并將其上傳到example-com/.well-known/acme-challenge/some_file。
- 愛麗絲簽署并上傳簽名后，要求Let's Encrypt其進行檢查。
- Let's Encrypt檢查是否可以訪問上的文件example-com，如果它成功下載了簽名并且簽名有效，則Let's Encrypt向Alice頒發證書。
這個過程的流程圖如下：
數字證書劫持
那么，我們假設Alice并不會實際擁有example-com，但是她通過中間劫持的方法實現了步驟5中進行加密。自從Let's Encrypt推出以來，這一直是個問題。事實上普林斯頓大學的一組研究人員在Bamboozling證書頒發機構的BGP中證明了這一點：他們執行了一個真實的BGP攻擊演示，以合乎道德的方式從頂級CA獲得虛假證書。為了評估PKI的脆弱性，研究人員收集了180萬個證書的數據集，發現這些數據集中絕大多數域都可以成功偽造證書。
該論文中，研究人員提出了兩種解決方案，以進行補救，或至少降低這些針對KPI攻擊的風險：
- CA機構從多個有利位置對域名進行驗證，以使其難以發起成功的攻擊;
- CA機構通過BGP監視系統，檢測可疑BGP路由并延遲證書驗證使網絡運營商有時間對BGP攻擊做出反應。
最近Let's Encrypt實現了第一個解決方案：多角度域驗證。該方法改變了上述流程的第5步：在新的策略下Let's Encrypt會從多個位置下載域名的證書驗證。
Let's Encrypt攻擊的工作原理
安德魯·艾耶(Andrew Ayer)在2015年發現了對Let's Encrypt的攻擊。在其中，Andrew提出了一種方法來控制已經驗證了域的Let's Encrypt帳戶(例如example-com)
攻擊是這樣的：
- Alice通過在example-com上的一些數據上載簽名(example-com/.well-known/acme-challenge/some_file) 來注冊并完成域驗證。然后，成功地從Let's Encrypt獲得證書。
- 之后Eve使用新帳戶和新的RSA公鑰簽署了Let's Encrypt，并請求恢復example-com域
- Let's Encrypt要求Eve簽發一些新數據，并將其上傳到example-com/.well-known/acme-challenge/some_file。
- Eve制作了一個新的假冒密鑰對，并在Let's Encrypt上更新了其公共密鑰。然后，她要求Let's Encrypt以檢查簽名。
- Let's Encrypt從example-com獲取簽名文件，簽名匹配，于是Eve被授予example-com域所有權。
攻擊的圖示如下：
在上述攻擊中，Eve設法創建了一個有效的公鑰，該公鑰驗證了給定的簽名和消息。數字簽名不能唯一地標識密鑰或消息
根據RSA的工作原理(這是現代證書交換鏈的基礎)：
對于固定簽名signature和(PKCS#1 v1.5)消息message，公鑰(e，N)必須滿足以下方程式以驗證簽名：
一個人可以很容易地制作一個(大部分時間)滿足以下等式的公鑰：
可以輕松驗證驗證是否有效：
根據定義，最后一行是正確的。
數字簽名的安全性
由于理論領域與應用領域之間安全性證明與已實施協議之間存在差距。密碼學中的簽名通常使用EUF-CMA模型進行分析，該模型代表自適應選擇消息攻擊下的存在不可偽造性。
通過模型中，生成了一個密鑰對，然后要求簽署一些任意消息。在觀察簽署的簽名時，如果可以在某個時間點對未請求的消息產生有效的簽名，將獲勝。
不幸的是，盡管現代簽名方案似乎通過了EUF-CMA測試，但它們往往表現出一些令人驚訝的特性。論文《Automated Analysis of Subtle Attacks on Protocols that Use Signatures》中Dennis Jackson，Cas Cremers，Katriel Cohn-Gordon和Ralf Sasse試圖對使用簽名的協議進行細微的攻擊的自動化分析，試圖列出這些令人驚訝的特性以及受它們影響的簽名方案(然后找到一堆)在使用正式驗證的協議。
保守的排他性(CEO)/破壞性的排他性(DEO)：
(1) 密鑰替換攻擊(CEO)，其中使用不同的密鑰對或公鑰來驗證給定消息上的給定簽名。
(2) 消息密鑰替換攻擊(DEO)，其中使用不同的密鑰對或公共密鑰來驗證新消息上的給定簽名。
- 可延展性。大多數簽名方案都是可塑的，這意味著如果給出一個有效的簽名，就可以對其進行篡改，以使其成為一個不同但仍然有效的簽名。請注意，如果我是簽名人，通常可以為同一條消息創建不同的簽名。不清楚這是否會對任何現實世界的協議產生影響，盡管比特幣MtGox交易所將其資金損失歸咎于該協議，2014年2月，曾經是最大的比特幣交易所MtGox關閉并申請破產，聲稱攻擊者利用可塑性攻擊來耗盡其帳戶。
請注意，一種新的安全模型SUF-CMA(用于強EUF-CMA)試圖將這種行為包含在簽名方案的安全定義中，并且一些最新標準(如RFC 8032指定Ed25519)正在緩解對其簽名方案的延展性攻擊。。
- 可重新簽名。這很容易解釋。要驗證消息上的簽名，通常不需要消息本身，但需要摘要。這樣，任何人都可以使用自己的密鑰重新簽名消息，而無需知道消息本身
- 可碰撞性。有些方案允許制作簽名，這些簽名將在幾條消息下進行驗證。更糟糕的是，按設計Ed25519允許人們制作公鑰和簽名，從而很有可能驗證任何消息。(在某些實現中，例如libsodium，此問題已修復。)
下圖中概括了證書替代攻擊：
最后，好的簽名方案會將有有效的安全的方法都會累積完善起來，所以在使用時候選擇主要的方法一般是沒有問題。而如果你要重復造輪子，要自己實現一套更為復雜的加密協議，則需要考慮這些問題。
