Opened 10 years ago
Closed 8 years ago
#425 closed defect (fixed)
ocsp stapling may send expired response
|Reported by:||Ryanne Fox||Owned by:|
|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 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
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
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:
(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 by , 10 years ago
|Status:||new → accepted|
comment:2 by , 10 years ago
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:3 by , 8 years ago
See these messages for proposed patches:
comment:5 by , 8 years ago
|Status:||accepted → closed|
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.