4 ms·
Apart from the advantage that it's very easy to prevent requests which don't have the required client certificate from even hitting your application, which is a
by bensummers 11y ago
Apart from the advantage that it's very easy to prevent requests which don't have the required client certificate from even hitting your application, which is a major security win.
- geofft 11y agoWell, they're hitting your web server because you don't want a hard-required client certificate. (I've administered a server relying on a larger deployment of client certs than OP's; browser compatibility is a mess, and `SSLVerifyClient require` is a mistake.) Yes, you can set things up on the server side so that it hits a static page instead of your web application. But you can do that with the JS-based solution too: have it send you to a login page with a signed query-parameter or similar, and verify that query parameter in the web server configuration. If it fails / doesn't exist, deliver a static site that includes the necessary JS to do the login. Your web server will need to verify a signature or MAC there, but this is way less attack surface than the usual client-cert processing code in SSL stacks (which processes untrusted keys and signatures). Removing that code will be an equal or greater security win. Basically, if there is interest in engineering a good application-level solution instead of relying on the transport-level one, it can absolutely be done. (I do freely admit there isn't anything that can be used out-of-the-box today, to my knowledge.)