怎么判断ssl证书配置（数字证书签名LetsEncrypt和证书劫持）
怎么判断ssl证书配置（数字证书签名LetsEncrypt和证书劫持）这些是ASN.1结构。现代的证书就是这样的：signatureValue BIT STRING }Certificate ::= SEQUENCE {tbsCertificate TBSCertificatesignatureAlgorithm AlgorithmIdentifier
现在安全体系中，最重要的一部分是数字安全加密体系，包括数字内容的加密解密，数字签名和验证。本文虫虫给大家介绍一下数字证书签名以及世界最大的网站Https免费签名Let's Encrypts，及数字证书签名的安全性等问题。
概述数字签名就是在信息的后面再加上一段内容，可以证明信息没有被修改过，怎么样可以达到这个效果呢？一般是对信息做不可逆的哈希计算得到一个哈希值。在把信息发送出去时，把这个哈希值加密后做为一个签名和信息一起发出去。接收方在收到信息后，会重新计算信息的哈希值，并和信息所附带的哈希值(解密后)进行对比，如果一致，就说明信息的内容没有被修改过。数字签名在现在现代安全体系中非常重要基础，可以用来确保文件的完整性、防止文件篡改以及身份认证等。首先我们说说几个常见的数字证书基本概念：
RFCRFC的意思是Request For Comments，中文对应为请求注释，它是一堆描述不同协议的文本文件。如果想了解SSL，TLS（新的SSL）和x509证书（用于SSL和TLS的证书）如何工作，例如，想编写自己的OpenSSL，则必须阅读相应的TLS RFC。：的X509证书对应的rfc5280和TLS（1.2）对应的rfc5246。
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验证即可：
openssl x509 -in cert.pem -noout -text
说到数字签名就不能不对Let's Encrypt竖起大拇指，可以说它以一己之力为整个互联网网站撑起了HTTPS的天。Let's Encrypt成立于2014年，是一家非盈利性的认证机构，目前为约2亿个网站提供了数字证书认证，累积签发了10亿张的证书。
Let's Encrypt成功的关键取决于两点：
它是免费的。Let's Encrypt之前，大多数证书颁发机构向要获得证书的网站管理员收取费用。
Let's Encrypt证书和商业证书的区别:
它是自动化的。如果遵循其标准化协议，则可以通过API请求，续订甚至吊销证书。与此形成对比的是其他证书机构需要手动处理并需要一些时间来颁发证书。
如果网站管理员希望网站example-com（通过HTTPS）向用户提供安全的连接，则可以向Let's Encrypt发出申请证书，并在证明自己拥有域example-com并颁发证书后，便可以使用该证书来与任何信任"Let's Encrypt"的浏览器协商安全连接。
这个实际流程如下：
1、Alice使用RSA公钥在Let's Encrypt中注册。
2、Alice要求Let's Encrypt证书example-com。
3、Let's Encrypt让Alice证明自己是example-com所有者，需要签发一些数据并将其上传到example-com/.well-known/acme-challenge/some_file。
4、爱丽丝签署并上传签名后，要求Let's Encrypt其进行检查。
5、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)：
密钥替换攻击（CEO），其中使用不同的密钥对或公钥来验证给定消息上的给定签名。
消息密钥替换攻击（DEO），其中使用不同的密钥对或公共密钥来验证新消息上的给定签名。
可延展性。大多数签名方案都是可塑的，这意味着如果给出一个有效的签名，就可以对其进行篡改，以使其成为一个不同但仍然有效的签名。请注意，如果我是签名人，通常可以为同一条消息创建不同的签名。不清楚这是否会对任何现实世界的协议产生影响，尽管比特币MtGox交易所将其资金损失归咎于该协议，2014年2月，曾经是最大的比特币交易所MtGox关闭并申请破产，声称攻击者利用可塑性攻击来耗尽其帐户。
请注意，一种新的安全模型SUF-CMA（用于强EUF-CMA）试图将这种行为包含在签名方案的安全定义中，并且一些最新标准（如RFC 8032指定Ed25519）正在缓解对其签名方案的延展性攻击。 。
可重新签名。这很容易解释。要验证消息上的签名，通常不需要消息本身，但需要摘要。这样，任何人都可以使用自己的密钥重新签名消息，而无需知道消息本身
可碰撞性。有些方案允许制作签名，这些签名将在几条消息下进行验证。更糟糕的是，按设计Ed25519允许人们制作公钥和签名，从而很有可能验证任何消息。（在某些实现中，例如libsodium，此问题已修复。）
下图中概括了证书替代攻击：
最后，好的签名方案会将有有效的安全的方法都会累积完善起来，所以在使用时候选择主要的方法一般是没有问题。而如果你要重复造轮子，要自己实现一套更为复杂的加密协议，则需要考虑这些问题。
