[squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[Amos Jeffries]

On 8/12/19 7:53 pm, George Sheng wrote:
> 
> Hi,
> 
> I’m new to this group. I just setup a squid ver 4.5 on my ubuntu

When using SSL-Bump one does need to use the latest release. Which is
4.9 now.

Since this is a custom build (4.5 has never been a release in Ubuntu)
you may find Squid-5 has even less issues for SSL-Bump.



...
> 2019/12/07 20:48:59.761 kid1| 83,5| Session.cc <http://Session.cc>(347)
> get_session_cb: Request to search for SSL_SESSION of
> len: 321019023443:419801955
> 2019/12/07 20:48:59.761 kid1| 54,5| MemMap.cc <http://MemMap.cc>(156)
> openForReading: trying to open slot for
> key 5310BD3C63AB0519C4F984A35A8DC1AE for reading in map [tls_session_cache]
> 2019/12/07 20:48:59.761 kid1| 54,5| MemMap.cc <http://MemMap.cc>(177)
> openForReadingAt: trying to open slot at 18 for reading in
> map [tls_session_cache]
> 2019/12/07 20:48:59.761 kid1| 54,5| MemMap.cc <http://MemMap.cc>(169)
> openForReading: failed to open slot for
> key 5310BD3C63AB0519C4F984A35A8DC1AE for reading in map [tls_session_cache]
> 2019/12/07 20:48:59.761 kid1| 83,5| Session.cc <http://Session.cc>(362)
> get_session_cb: Failed to retrieve SSL_SESSION from cache
> ***

This is talking about Squid's internal cache of TLS sessions that
clients have negotiated previously with this Squid. It means the client
is attempting to use/resume a TLS session ID that does not exist. There
is nothing anyone can do about that.


> 
> Here is my squid.conf:
> 
...
> https_port 3130 intercept ssl-bump
> cert=/usr/local/squid/etc/ssl_cert/myCA.pem
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> key=/usr/local/
> squid/etc/ssl_cert/myCA.pem
> 

FYI: with cert= and key= pointing at the same file you do not need the
key= option.


> ##
> 
> I’m wondering if this problem is a bug, my proxy config issue, or the
> client does not send the correct TLS parameters.
> thanks for your help in advance.
> 

The problem is most likely the client.

If the session ID actually was negotiated previously with this Squid
there may be shared-memory issues on your machine. Even with only one
worker this cache uses SMP functionality

If you only just started this Squid, the session may have been
negotiated with the origin or previous Squid instance. In that case it
is normal to get at least a few of these until they timeout and/or get
renegotiated.


Amos