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的情况下调用上述方法.我希望如果有人认证连接不需要重新协商.

但是我注意到在大多数浏览器上,如果我想获得会话并返回X509证书,我每次都需要调用sslh.handshake().如果"fetch"设置为false,那么我大部分都会返回None.

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

PS.

• 上面的代码是WebID协议实现的一部分
• 这是使用netty 3.2.5Final.我也试过3.2.7Final没有更多的运气.
• 所以我不得不改变运行上面代码的当前服务的代码,以便它总是强制握手(参见提交)但是这并没有给我足够的灵活性,就像我希望的那样.

Answer 1

事实证明，我在使用 unfiltered 的 netty 时遇到了问题。我在 Play 2.0 上实现相同的功能时发现了这一点。

请参阅Play2.0 上的错误报告 215和未过滤的错误 111：安全 netty 在每个连接上创建新的 TLS 上下文