网络认证为什么不选择OpenPGP?

安全
在实际网络应用中,传输层安全协议(TLS)是默认的强加密解决方案,但也许这种情况是不应该出现。为什么没有出现针对它的挑战,TLS加密中出现的所有问题都被忽视了么?本文来为大家进行详细分析。

TLS(包括其前身的名称,SSL)在进行网络认证时,加密协议的作用就是提供强加密的解决方案。尽管在加密认证中也存在其它可供选择的项目,举例来说,HTTP摘要式身份验证,它们倾向于使用较弱的结构。但对于HTTP摘要式身份验证来说,最大的问题就是这样的一个事实,它无法提供识别服务器的核查机制。这让它非常容易遭受到中间人类型的网络攻击。

 

与此相反,在设计的时间TLS协议就专门考虑到这种情况,并采用了权威的PKI证书来对服务器进行验证。该证书制度属于技术相关的过程,基于来自第三方的认证授权来对服务器进行验证;从某些方面来看,类似采用OpenPGP公钥加密信任模型的网络,但和官僚机构的结合性更高。

来自信任网络的主要部分属于它的转折点,但是:不是依靠个人判断来选择是否信任,取而代之的是自私自利的商业认证公司来公司使用者谁可以相信,谁不能被信任。

 

认证中心系统分为TLS和浏览器使用的HTTPS协议,这样的话,即使使用者希望使用类似Perspectives之类的独立认证核查系统,或者Monkeysphere之类信任网络的话,也还需要对于系统进行繁琐的设置,以便替代CA公钥基础设施。

在不包含电子商务要求的自签名证书中,基本上没有比CA签名的注册证书更容易设置的了。传统TLS认证模式的静态IP地址认证不会被自签名证书解除,或者被基于OpenPGP之类的其它公共密钥加密协议的技术所限制。

 

TLS中存在的问题有什么?

 

在很多情况下,基于TLS的PKI都会出现问题。举例来说,对于资源不足又需要安全认证的网站来说,由商业机构或者财力雄厚的爱好者来提供支持是不合适的。主机共享,采用便宜的方式来建立一家“真正”的网站,处理使用TLS保护认证时出现的一些令人不快的问题(举例来说,共享IP地址)。当然,为了保障服务器认证和强加密方面的认证保护,这些困难是无法消除的。

 

在理论上,这是一个可以获得解决的问题。作为一种加密协议,OpenPGP的基本结构是在大约二十年前由加密爱好者眼中的英雄菲尔•齐默尔曼设计的。对于个人、公司和站点来说,在加密/解密过程的半程中使用简单的公钥可以实现非常灵活的设置,并且支持带外模式的密钥核查认证。

它采用了大范围的分配机制,并且可以用来进行外部核查。这里面可以包括作为传统OpenPGP默认密钥验证过程服务的网络信任模式,以及Perspectives提供的分布式系统。

 

不过,理论和现实很少一致,在现实环境中,这并不属于一个已经获得解决的问题。实际情况是,TLS的应用范围是如此广泛,以至于已经成为了唯一的选择,没有其它竞争者可以对其构成威胁,甚至连达到类似水平的要求都做不到。

没有一家竞争对手,可以对CA的公钥基础设施构成最基本的威胁,它们甚至连挑战的机会都没有,就更不用说市场份额了。所有这一切让网络身份认证的简单实现基本覆盖所有标准共享主机的想法成为不可能,在每一个使用OpenPGP之类的外部公共密钥加密协议的案例中:单独CGI的执行情况和PHP实现,都让TLS成为不合理的负担。即使出现了一定的成功,包括Ruby on Rails、Django、CMSplug-ins在内的其它竞争对手也将很快跟进。

 

并且不幸的是,部署加密措施的操作很难做到。对于真正基于OpenPGP的网络认证简单实现来说,实施的时间需要了解对服务器运行的软件类型进行假设,这不是什么很方便的事情;或者与OpenPGP的应用与服务器端软件开发人员使用的语言种类有关。

在处理主机共享,而网络开发人员对于系统中安装的软件没有或者只有很少的控制权,大部分服务器端语言中常见的加密库都使用来自共享主机的同样外部工具(通常情况下是GnuPG)来作为OpenPGP支持部分的情况下,这么做是一件非常困难的事情。

 

让我们不要忘记处理客户端的艰巨性。功能丰富的新型浏览器可以利用基于HTTPS的URI模式来支持TLS加密。然而,它们不会采用内置OpenPGP的方式来支持网络身份认证。包含强大插件功能的浏览器可以采用相对简单的方法来为系统增加功能,至少在某些情况下可以实现这一点;但插件需要进行开发,并且这样做还涉及到客户端上安装的语言和分布式软件的情况,与共享主机上的软件可用性相比,这样的认证系统的可靠性更低。

 

OpenPGP面临的另一项挑战

 

最终,我们找出了为什么没有以OpenPGP或类似独立公共密钥加密为基础的竞争对手可以替代TLS的原因。所有的努力都需要从基层开始,举例来说,开源软件开发社区应该提供整体解决方案,以自下而上的方式揭开针对基于CA的PKI加密模式在实际网络中的霸权进行挑战的序幕。

如果没有具备前瞻性的大学生或者巨型企业支持的话,这样的工作将会是非常难以进行的,毕竟,建立一个新的网络身份认证体系需要做的工作非常多。更糟糕的可能是,即便这样的开源系统得以建立,由于合理性或者资金方面的问题可能会导致它采用许可模式(估计会是非盈利版权)发放,这在某些情况下会阻碍代码的使用,从而限制其推广。

这还没有包含对易于使用的标准化带外密钥验证系统的要求,尽管在理论上它并不属于系统的组成部分,但对于达到广泛普及的目标来说将会起到非常大的作用。

 

尽管如此,但这种做法看起来似乎是目前唯一最有可能并且最简单的方式,可以代替TLS提供更为“民主”的选择;至少在验证领域的情况是这样,我们甚至预计最终可以普及到全程加密。

OpenPGP尽管在本文中被我采用,而且作为典例来进行说明,但SSH协议在这方面的效果也非常好。 希望读者多多关注这方面的知识。

【编辑推荐】

  1. 安全3.3的三大必要条件
  2. 浅析黑客技术和网络安全
  3. 别让恶意软件妨碍我们的生活
  4. 大多数企业忽视“网络间谍”的威胁
  5. IT人员的困绕:互联网早期的病毒传播
  6. 无线不可靠?常见无线网络安全问题解与答
责任编辑:佚名 来源: 机房360
相关推荐

2009-12-21 17:11:38

Linux认证

2019-07-08 10:28:33

网络认证供应商自动化

2011-11-28 10:21:52

Nginx特性

2012-02-28 09:11:51

语言Lua

2009-06-25 15:09:34

选择JSFESRI

2024-01-15 00:42:55

Go语言应用程序

2020-06-10 09:06:48

MongoDB架构高可用

2013-10-22 15:18:19

2023-02-26 01:25:23

Sanic框架工具

2016-08-19 16:27:52

数据库Mongo DB开发

2017-02-27 15:19:04

2012-11-14 20:55:07

容错服务器选型CIO

2015-07-06 15:09:10

隧道封装Docker公有云

2024-03-11 11:02:03

Date类JavaAPI

2013-03-13 03:58:12

马云人大代表两会

2024-11-29 08:20:22

Autowired场景项目

2016-10-11 16:31:56

微信服务器消息

2022-01-11 10:29:32

Docker文件挂载

2024-10-25 14:39:26

BigDecimal精度数值

2023-03-21 08:02:36

Redis6.0IO多线程
点赞
收藏

51CTO技术栈公众号