Bug #2568
closedAll sockets share ca-file settings
Description
I just upgraded to 1.4.35 and have narrowed down the cause of slower connection speeds on TLS to lighttpd increasing my certificate chains by 50% after git commit 1af871fcef97574c71870309d572d6b1026ee605.
For some reason lighttpd is now unnecessarily adding 2000 bytes to TLS handshakes, and with the StartSSL intermediary certificate being signed by two different root certificates, if a browser has a different StartCom CA certificate to the one that is being forcefully sent that is a pointless waste of precious bytes, especially since there is no requirement for the root certificate to be sent at all.
Qualys now lists "contains anchor" next to one of the trust paths. All the best practices regarding speeding up SSL/TLS connections say "reduce the size of your certificate chain". lighttpd now increases my certificate chains by 50% - handshakes after the change go from 4,408/446 bytes (read/wrote by client) to 6,408/446 bytes.
The commit message mentions SNI, so it probably means I can get rid of the ca-file lines for each SNI HOST. But none of those include the root certificate anyway.
... ...
I don't understand this.
IP address 149.255.99.49 is set-up with SNI.
IP addresses [2001:470:1f09:38d::80:1], and [2a03:ca80:8000:7673::18] do not use SNI but are in the same vhost file.
None of them include the root certificate in their ca-file's.
If all other SSL vhosts/sockets are disabled, the handshake size goes back down to 4,408 bytes.
A different vhost file listens on [2001:470:1f09:38d::80:9] with a certificate that expired years ago - I'm sure I'm not the only person that has vhost files he has forgotten about. It doesn't use SNI but does include the root certificate in its ca-file. If I include that vhost file, all handshakes are 6,406 bytes (including those on completely different IP addresses).
A different vhost listens on 149.255.99.50 and [2001:470:1f09:38d::80:11] and doesn't use SNI but does include the root certificate in its ca-file. If I include that vhost file, all handshakes are 6,408 bytes (including those on completely different IP addresses).
It took me 3 hours to find out lighttpd was the cause of larger TLS handshakes, and a further 6 hours to narrow down why.
Surely the settings for one "socket" shouldn't change the settings for a different "socket"?
Updated by stbuehler over 10 years ago
- Status changed from New to Wontfix
I'm not going to list the reasons again. The crappy openssl API and our "special" config make any sane handling nearly impossible. I think I've wasted more than one week on this (trying to find better solutions), and I'm done with it.
Updated by gstrauss over 3 years ago
- Status changed from Wontfix to Fixed
- Target version set to 1.4.x
- ASK QUESTIONS IN Forums set to No
lighttpd 1.4.56 (released Nov 2020) migrated to a "newer" OpenSSL API (available since openssl 1.0.2). Admins are encouraged to always include the full chain (minus the final root cert) in ssl.pemfile. Prior to lighttpd 1.4.56, ssl.pemfile in $SERVER["socket"] would use the full chain, if provided, but only the first certificate was used from ssl.pemfile in $HTTP["host"]. This has been fixed in lighttpd 1.4.56 -- lighttpd uses the full chain whenever it is provided in ssl.pemfile, and you can supply precisely the chain to be sent. lighttpd 1.4.56 also suppports OCSP stapling, if you provide (and maintain) a .der file containing a valid OCSP response.
If the full chain is included in ssl.pemfile, then ssl.ca-file is not used to build the server certificate chain and ssl.ca-file is used only for client cert verification, if client cert verification is configured. Since lighttpd 1.4.46 (released Oct 2017), you have been able to specify ssl.ca-dn-file to contain (only) the client signing CA (even if an intermediary) that the client should use for issuer DN when selecting a certificate to send in response to a server client-cert-request.
Also available in: Atom