带自签名证书的SSL上的OpenID

为您的OpenID URL使用SSL的主要好处是,它为依赖方提供了一种机制来发现DNS是否被篡改。依赖方不可能知道带有自签名证书的OpenID URL是否已被破坏。

在提供程序的端点URL上使用SSL还有其他好处(更容易建立关联,不窃听扩展数据),如果使用自签名证书,这些好处仍然有效,但我认为它们是次要的。

OpenID是以重定向透明方式设计的。只要在每次重定向时保留必要的键/值对,无论是通过get还是post,一切都将正常运行。

与不使用自签名证书的使用者兼容的最简单解决方案是使用非加密的端点,该端点重定向 checkid_immediate 和 checkid_setup 发送给加密邮件。

在服务器代码中这样做比使用Web服务器重定向更容易,因为前者可以更容易地处理POST请求,同时还可以将代码保持在一起。此外,您可以使用相同的端点来处理所有OpenID操作,不管它是否应该通过SSL提供,只要完成了适当的检查。

例如,在PHP中,重定向可以简单如下:

// Redirect OpenID authentication requests to https:// of same URL
// Assuming valid OpenID operation over GET
if (!isset($_SERVER['HTTPS']) &&
        ($_GET['openid_mode'] == 'checkid_immediate' ||
         $_GET['openid_mode'] == 'checkid_setup'))
    http_redirect("https://{$_SERVER['HTTP_HOST']}{$_SERVER['REQUEST_URI']}");

作为 openid.return_to 值是针对普通HTTP端点生成的,就使用者而言,它只处理非加密服务器。假设openid 2.0对sessions和nonce进行了正确的操作,那么无论用户和服务器之间传递的是什么信息,都不应该显示可利用的信息。浏览器和OpenID服务器之间的可利用操作(密码监听或会话cookie劫持)是通过加密通道完成的。

除了防止窃听者,通过SSL执行身份验证操作还允许您使用 secure HTTP cookie标志。这为 立即检查 操作,如果您希望允许的话。

(免责声明:我对OpenID不熟悉,所以这里可能是错的。)开放ID使用者(例如stackoverflow)和开放ID提供者(您的服务器)之间的通信不需要HTTPS——它在纯HTTP上也能同样安全地工作。您需要做的是将服务器配置为仅在显示登录页面时切换到HTTPS。在这种情况下,只有您的浏览器需要关注自签名证书。您可以将证书导入到您的PC上,一切都将像Verisign颁发的证书一样安全。

听起来不错。OpenID服务器的客户端不信任根证书颁发机构。