Question

我有一个100％https的Web服务器，可以进行TLS重新协商。这非常有用，因此用户可以在单击登录按钮并询问其客户端证书之前访问该站点并获取一些不错的页面。以下是重新协商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客户端证书进行身份验证，会话将持续一段时间并记住证书链 - 比如10分钟或更长时间，并且在任何情况下至少1分钟。实际上，这就是为什么我可以选择在变量“fetch”设置为false的情况下调用上述方法。我希望如果有人认证连接不需要重新协商。

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

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

PS。

上面的代码是WebID protocol
这是使用netty 3.2.5Final。我也试过3.2.7Final而没有更多的运气。
所以我不得不更改current service running the above code的代码，以便它总是强制握手（参见the commit）但这并没有给我足够的灵活性。

Answer 1

事实证明我遇到了未经过滤的netty问题。我在Play 2.0上实现了相同的功能。

请参阅bug report 215 on Play2.0和未过滤的bug 111: secure netty creates new TLS contexts on each connection

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

1 个答案: