[gnutls-devel] OCSP RFC6961 for web servers

[Nikos Mavrogiannopoulos]

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.

regards,
Nikos