Change https://golang.org/cl/317931 mentions this issue: crypto/tls: use a cache to save x509 certificate in the tls connection

Aren't those parsed certificates also passed to user-provided code? Like with tls.Config's VerifyPeerCertificate, for example? What happens when that code mutates the cached certificates?

Not to mention that they're never deleted...

Aren't those parsed certificates also passed to user-provided code? Like with tls.Config's VerifyPeerCertificate, for example? What happens when that code mutates the cached certificates?

The x509.Certificate is stateless,I think if the cached certificate is also used elsewhere, it will have no effect.

Aren't those parsed certificates also passed to user-provided code? Like with tls.Config's VerifyPeerCertificate, for example? What happens when that code mutates the cached certificates?

If user-provided code also wanna parse certificate with cache, needs add an export function, but i do not sure if it is necessary

Not to mention that they're never deleted...

Yes, the current cache does not provide a delete/expiration plan. Maybe set a maximum cache size is a simple way to control the cache memory use, but it is difficult to determine what this value is

Not to mention that they're never deleted...

How about add an expire time to the cache. The cache keeps the time that cache was cleaned, Whenever the cache needs to be updated, it is judged whether the expiration time is reached. If it is, the previous cache is cleared.

just like:

type Cache struct {
  lastCleaned time.Time 
}

const expire time.Duration = xxxxx // set a expire 

func (c *Cache) Update() {
  now := time.Now()
  if now.Sub(expire) >= c.lastCleaned {
     // clean the cache
  }
}

Aren't those parsed certificates also passed to user-provided code? Like with tls.Config's VerifyPeerCertificate, for example? What happens when that code mutates the cached certificates?

A way to not increase the export function is to directly put the cache in the x509.ParseCertificate?

/cc @FiloSottile

ping @rolandshoemaker @FiloSottile

ping @FiloSottile

hello， any suggestions for this issue/ pr ? @FiloSottile @cagedmantis

I'm also interested in this, as we've also seen it in production.

I'd prefer an approach that adds an x509 cache field to the tls.Config struct (defaulting to nil) along with an associated interface. Then users can opt into a cache, taking responsibility for the integrity of the data within and for designing their own eviction strategies.

we found boring ssl have certificate cache too, see https://boringssl.googlesource.com/boringssl/+/HEAD/PORTING.md#crypto_buffer

With the standard OpenSSL APIs, when making many TLS connections, the certificate data for each connection is retained in memory in an expensive X509 structure. Additionally, common certificates often appear in the chains for multiple connections and are needlessly duplicated in memory.

Change https://go.dev/cl/426455 mentions this issue: crypto/tls: use certificate cache in client

Change https://go.dev/cl/426454 mentions this issue: crypto/tls: add a certificate cache implementation