Netty https（TLS）会话持续时间：为什么需要重新协商？

Question

我有一个100%的https Web服务器，支持TLS重新协商。这非常有用，因为用户可以访问网站并获取一些漂亮的页面，然后再点击登录按钮并被要求提供客户端证书。以下是执行重新协商的代码部分 X509Cert类的213-236行。

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客户端证书进行身份验证，会话将持续一段时间并记住该证书链 - 例如10分钟或更长时间，在任何情况下至少为1分钟。事实上，这就是为什么我有一个选项调用上述方法时将变量“fetch”设置为false。我希望如果有人验证了连接，则不需要重新协商连接。

但是我注意到在我的浏览器上，大多数情况下似乎需要每次调用sslh.handshake()才能获取会话并返回X509证书。如果“fetch”设置为false，则大多数情况下我会返回None。

这是正常的吗，还是我做错了什么？

附言。

• 上面的代码是 WebID协议 的实现之一。
• 这是使用的 netty 3.2.5Final。我也尝试过3.2.7Final，但没有更好的运气。
• 所以我不得不更改 运行上述代码的当前服务 的代码，以便它始终强制进行握手（参见此提交）。但这并没有给我带来我希望拥有的那么多灵活性。

- Henry Story

Answer 1

原来我遇到的问题是与unfiltered使用netty有关。当我在Play 2.0上实施相同的操作时，发现了这个问题。

请参阅Play2.0上的错误报告215，以及在unfiltered上的错误111: 安全的netty在每个连接上创建新的TLS上下文。

- Henry Story