Opened 6 years ago

Closed 4 years ago

#425 closed defect (fixed)

ocsp stapling may send expired response

Reported by: www.google.com/accounts/o8/id?id=AItOawmXG9_vdIJ9rPCn9BZe6-svpp4mPofu7qk Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.3.x
Keywords: Cc:
uname -a: Linux hostname 2.6.18-348.16.1.el5 #1 SMP Wed Aug 21 04:00:25 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.4.3 built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54) TLS SNI support enabled configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_ssl_module --with-http_spdy_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module --with-http_image_filter_module --with-http_geoip_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-mail --with-file-aio --with-mail_ssl_module --with-ipv6 --with-openssl=/builddir/build/BUILD/openssl-1.0.1e --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-debug

Description

In some conditions, Nginx when configured with 'ssl_stapling on' may send an expired response to a client. When a client receives this invalid response, it aborts the handshake, per RFC6066.

Clients requesting an OCSP response and receiving an OCSP response in
a "CertificateStatus?" message MUST check the OCSP response and abort
the handshake if the response is not satisfactory with
bad_certificate_status_response(113) alert. This alert is always
fatal.

Better behavior from Nginx would be to continue the handshake without including a CertificateStatus? message, so the client may attempt to retrieve a valid response itself.

A suggestion from Kaspar Brand, looking at this issue from Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=923887#c2), was:

A flaw in the OCSP stapling code in nginx, it seems:

http://trac.nginx.org/nginx/browser/nginx/src/event/ngx_event_openssl_stapling.c#L449

(should check for an expired response first, and not call ngx_ssl_stapling_update only after having handed out the current/old response)

Change History (5)

comment:1 Changed 6 years ago by mdounin

  • Status changed from new to accepted

The code in question checks if it's time to obtain new OCSP response (which happens in an hour after a OCSP response was obtained), not certificate status response expiration. The fact that an expired OCSP response was served indicate that a site had no requests for a long time to trigger a reload process (or it wasn't able to load new response due to some problems) and the response was expired. Additional check should be added to make sure expired responses are not served to clients in such cases.

comment:2 Changed 6 years ago by mdounin

Just a side note. I tend to think that following quoted RFC6066 requirement might not be a good idea in real life. As far as I can tell, this can be easily used to DoS a server if an OCSP response signature isn't checked, and this seems to be the case at least in nginx (by default, as this requires additional root certificates to be configured, at least with previous OpenSSL versions) and in Apache (it looks like there is no OCSP response signature validation in the OCSP stapling code at all).

comment:4 Changed 4 years ago by Maxim Dounin <mdounin@…>

In 6893a1007a7c7e91e0afeb9c537c5bcecf937faa/nginx:

OCSP stapling: avoid sending expired responses (ticket #425).

comment:5 Changed 4 years ago by mdounin

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.