You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There should be a configuration option which requires to validate clients' certificates. The functionality requires DNS resolving, so user- vs kernel- space implementation is TBD (see net/dns_resolver). Basically, the same implementation issues as for #769 (Full TLS proxying). In this sense DoH #1104 as a DNS recursive server would be beneficial.
Requires OCSP stapling, #831. For a server that is often dealing with many clients, all with certificates from the same CA, CRL checking can be significantly more efficient than OCSP because the CRL can be downloaded once per day instead of needing to check OCSP for every connection.
There should be a configuration option which requires to validate clients' certificates. The functionality requires DNS resolving, so user- vs kernel- space implementation is TBD (see
net/dns_resolver
). Basically, the same implementation issues as for #769 (Full TLS proxying). In this sense DoH #1104 as a DNS recursive server would be beneficial.Requires OCSP stapling, #831. For a server that is often dealing with many clients, all with certificates from the same CA, CRL checking can be significantly more efficient than OCSP because the CRL can be downloaded once per day instead of needing to check OCSP for every connection.
Tests
Frankencert fuzzing (see the original paper) can be used for testing.
The text was updated successfully, but these errors were encountered: