session - Netty https ( TLS ) session 持续时间 : why is renegotiation needed?

Question

我有一个进行 TLS 重新协商的 100% https 网络服务器。这非常有用，因此用户可以在单击登录按钮并被要求提供客户证书之前访问该站点并获得一些漂亮的页面。下面是重新协商的代码部分 line 213-236 of X509Cert class

import org.jboss.netty.handler.ssl.SslHandler

val sslh = r.underlying.context.getPipeline.get(classOf[SslHandler])

trySome(sslh.getEngine.getSession.getPeerCertificates.toIndexedSeq) orElse {
  if (!fetch) None
  else {
    sslh.setEnableRenegotiation(true) // todo: does this have to be done on every request?
    r match {
      case UserAgent(agent) if needAuth(agent) => sslh.getEngine.setNeedClientAuth(true)
      case _ => sslh.getEngine.setWantClientAuth(true)
    }
    val future = sslh.handshake()
    future.await(30000) //that's certainly way too long.
    if (future.isDone && future.isSuccess)
      trySome(sslh.getEngine.getSession.getPeerCertificates.toIndexedSeq)
    else
      None
  }
}

现在我期待一旦有人使用 X509 客户端证书进行身份验证， session 将持续一段时间并记住证书链 - 比如说 10 分钟或更长时间，无论如何至少 1 分钟。事实上，这就是为什么我可以选择调用上述方法并将变量“fetch”设置为 false。我希望如果有人对连接进行了身份验证，则不需要重新协商。

但我注意到，在大多数浏览器中，如果我想获得 session 并返回 X509 证书，我似乎每次都需要调用 sslh.handshake()。如果“fetch”设置为 false，那么我通常会返回 None。

这是正常现象，还是我做错了什么？

附言。

• 上面的代码是 WebID protocol 实现的一部分
• 这是使用 netty 3.2.5Final。我也尝试过 3.2.7Final，但运气不佳。
• 所以我不得不更改 current service running the above code 的代码所以它总是强制握手(参见 the commit)但这并没有给我希望的灵 active 。

Answer 1

事实证明我在使用 netty 时遇到了未过滤的问题。我在 Play 2.0 上实现相同时发现了这一点。

参见 bug report 215 on Play2.0 ，以及未过滤的 bug 111: secure netty creates new TLS contexts on each connection