[gnutls-devel] OCSP RFC6961 for web servers
nmav at gnutls.org
Wed Feb 4 17:29:33 CET 2015
On Wed, 2015-02-04 at 16:48 +0100, Tim Ruehsen wrote:
> On Wednesday 04 February 2015 11:01:19 Nikos Mavrogiannopoulos wrote:
> > However, at the current state the
> > packets generated seem to be in accordance with wireshark, so as far as
> > I understand, it remains to properly support it on the server side by
> > enhancing the ocsptool to generate a combined status request, as well as
> > accounting the multiple OCSP responses received on peer's certificate
> > verification.
> Please help me to understand it.
> I thought ocsptool is to generate requests (and responses) for OCSP
> responders. What has this to do with the TLS extension status_request_v2
> (despite the fact that a HTTPS server could use the responses to build
> status_request_v2 stapled responses for the 'Server Hello').
Exactly (though, the status request response isn't sent on server
hello). We need a way/tool for server operators to gather and
concatenate their OCSP responses in a format gnutls will understand.
ocsptool ought to do that.
> So in my understanding, we have to address the webserver people to support
> OCSP (multi-)stapling via GnuTLS (e.g. apache mod_gnutls or mod_ssl people).
That's in addition to the above.
> BTW, how trustworthy is OCSP stapling at all ? While ClientHello/ServerHello
> we are vulnerable to MITM. Couldn't this lead to a manipulated status_request
> answer, which tells the client that the cert is valid (not revoked) ?
A modification of the handshake would be detected at the finished
messages in TLS, so a MitM wouldn't work. In fact an attack which
replaces an OCSP response with an other (e.g. a previous one which is
still valid), would work with the HTTP OCSP requests, but not over TLS.
More information about the Gnutls-devel