在android应用程序的API情况下，EV SSL证书在使用而不是自签名ssl时有什么不同吗？

Question

我知道，在dns欺骗的情况下，自签名ssl是有风险的，因为攻击者可能自己生成一个自签名ssl并将其放置在他的ip地址中，并且它将在客户端browser.But中触发一个警告，这会使EV SSL在dns欺骗时不同于自签名ssl吗?我将只从我的android客户端应用程序向该自签名ssl站点发送流量，我是否自己进行了这些检查(那些检查浏览器在获得ssl证书时所做的检查)？

Answer 1

如果你特别偏执某人欺骗dns和证书(自签名，EV或其他)，那么您可以静态地信任自签名证书，例如检查指纹或subjectKeyId (滑雪)。启动连接时，在继续之前，根据已知的良好指纹/哈希检查所提供的证书。

这确实有一个缺点，那就是撤销证书需要对应用程序进行更新，这在很大程度上是PKI设计所避免的。

请注意，EV属性不是技术差异，而是策略差异。这是CA的一个承诺，即他们已经验证了他们颁发证书的公司的身份，而不仅仅是域名。您只能信任EV证书，而不是信任正在声明该语句的CA。YMMV

Answer 2

一般来说，有三种证书：

自签名证书：

这些证书通常由内部证书颁发机构(CA)生成，其中将根证书注入到所有客户端。这样，当通过TLS访问内部web应用程序时，不会向最终用户显示证书警告。

签名证书：

这些证书是由公开或面向internet的证书颁发机构(CA)签署的。这些CA的根证书随web浏览器而来。

EV签名证书：

EV证书与签署证书一节中所描述的相同，但是，通过获得这样的证书，颁发者必须检索更多关于要求该证书的公司的信息。

在发出EV证书之前，将进行额外的检查。

在android应用程序的API情况下，EV SSL证书在使用而不是自签名SSL时有什么不同吗？

是的，这确实产生了影响，在生产环境中不应该使用自签名证书。

不同之处在于，对于自签名证书，用户将收到警告。如果有人在中间攻击，证书是无效的，用户也将收到警告。

被告知总是接受这些警告的用户容易在攻击过程中受到人为攻击。

使用有效证书时，不显示带有证书警告的用户。当一个人在中间攻击发生时，用户会看到一个警告，这应该表明有什么地方不对劲。

现在，没有使用自签名证书的有效理由。可以很容易地获得免费证书。在我看来，使用EV证书将是过分的。

Answer 3

为了保护Android应用程序的API，可以使用自签名证书。如果您插入多个证书(甚至您自己的CA)，并且只使用一个证书，您甚至可以在不更新应用程序的情况下撤销它们。

这是很少的情况下，自我签名，DV或EV没有区别。请确保在所有与应用程序相关的网站上至少使用DV，以及与这些网站相关的API，否则用户将收到警告。