[gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2'

[Tim Ruehsen]

On Wednesday 04 February 2015 14:44:45 Tim Ruehsen wrote:
> On Wednesday 04 February 2015 14:33:58 Nikos Mavrogiannopoulos wrote:
> > On Wed, 2015-02-04 at 14:23 +0100, Tim Ruehsen wrote:
> > > On Wednesday 04 February 2015 12:34:15 Nikos Mavrogiannopoulos wrote:
> > > > On Wed, 2015-02-04 at 11:35 +0100, Tim Ruehsen wrote:
> > > > > On Wednesday 04 February 2015 11:22:29 Nikos Mavrogiannopoulos 
wrote:
> > > > > > On Wed, 2015-02-04 at 11:05 +0100, Tim Ruehsen wrote:
> > > > > > > > I don't think that this is related. 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.
> > > > > > > 
> > > > > > > The fix just handles the case where status_request and
> > > > > > > status_request_v2
> > > > > > > both are sent (client hello), but the answer (server hello) just
> > > > > > > includes
> > > > > > > status_request.
> > > > > > > I guess, that will be pretty common the next few months/years.
> > > > > > 
> > > > > > Ok, thanks. I've handled it a bit differently.
> > > > > 
> > > > > Sorry, Nikos.
> > > > > I just pulled it and it does not work.
> > > > > gnutls_ocsp_status_request_is_checked still returns 0 though there
> > > > > is
> > > > > a
> > > > > status_request answer.
> > > > > Just apply my first patch
> > > > > 0001-add-OCSP-multi-stapling-test-code.patch
> > > > > ...
> > > > > it just adds some printf to show that.
> > > > 
> > > > Ok. It was only working when the V2 request wasn't sent. I've now
> > > > updated the fix to work in all scenarios.
> > > 
> > > Thanks, Nikos !
> > > 
> > > IMO, there are two little glitch in your code.
> > > Guess idx==0 and the first ret becomes < 0... this is not catched, than
> > > you
> > > will use priv = epriv.ptr though epriv is uninitialized (or NULL).
> > > Looks like a crash in this case.
> > 
> > Wouldn't that be caught by:
> > if (idx == 0 && (ret < 0 ||
> > ((status_request_ext_st*)epriv.ptr)->responses_size == 0))
> > ? (the idx == 0 && ret < 0 part).
> 
> Yes, I meant idx!=0 and first ret < 0. Sorry.

Sorry, forget it ;-)

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150204/15835cd9/attachment.sig>