3 ms·
Doesn't this potentially create security problems if process lifetime is very long? Changes to the certificate store on the system will potentially not be picke
by korijn 2y ago
Doesn't this potentially create security problems if process lifetime is very long? Changes to the certificate store on the system will potentially not be picked up?
- marcosdumay 2y agoTechnically, yes. On practice, we are talking about the root certificates store. That thing that organizations update every 10 or 20 years. Every other year there's an update there, because there are a few of them, but your "very long" there uses a strong "very".
- korijn 2y agoWell, it doesn't necessarily have to be 10 or 20 years long, all it takes is for the timeframe to overlap with a certificate being revoked, I guess. Process lifetimes of a few months are definitely not uncommon. Anyway, I can see the tradeoff. There just needs to be a mechanism to disable this performance optimization, or to invalidate the cache (e.g. periodically).
- cryptonector 2y agoYes. And not just a security problem but an operational problem, since if you have to rotate a trust anchor you might have a hard time finding and restarting all such long-lived processes. IMO SSL_CTX_load_verify_locations() should reload the trust store when it changes, though not more often than once a minute. IMO all TLS libraries should work that way, at least when the trust anchors are stored in external systems that can be re-read (e.g., files, directories, registries, etc.). Apps can do something like that by re-creating an SSL_CTX when the current one is older than some number of minutes.