There are no TLS ciphersuites using CAST, so you can determine that one without looking at any actual data of any kind from any connection(s).
Yes, you can always tell passively (merely by looking) at a TLS handshake the selected ciphersuite. Note ciphersuites containing 'SHA' (meaning SHA1) use it only for the key derivation (called PRF through 1.2), and HMAC through 1.1 (always) or in 1.2 for any CBC-mode cipher or RC4 -- but RC4 is so weakened it should never be used at all according to rfc7465 in 2015. Using SHA1 or even MD5 in key derivation or HMAC is not a weakness; their breakage for collision only endangers certificates. (And actually not all certificates, but enough that the consensus is to ban them entirely.) You should definitely worry about any use of single-DES, as well as the 'export' suites with DES-40 or RC4-40 (as above, even full-strength RC4-128 is now officially prohibited). Some people worry about Triple-DES (written 3DES_EDE_CBC in the RFC names, and 3DES-CBC3 in OpenSSL's scheme) because of the generic birthday bound for 64-bit block -- see https://www.sweet32.org -- but for many applications, e.g. accessing StackExchange, this is not a problem. IDEA in principle also has the 64-bit block issue, but it is very rarely used, mostly because its patent status caused many people to avoid it in the past, and now there's no reason, benefit or incentive to go back to it instead of newer, better options.
Through 1.2 you can also see the server certificate chain (which will almost always be two and occasionally more, not 'a' certificate as you asked) and check the signing algorithms, and key sizes which is more important. MD5 and SHA1 broken for collision does endanger certs, as above, and as a result no cert issued by a public CA after about 2008 uses MD5 and none after 2015 or at most 2016 uses SHA1 for signature -- and the certs issued before that are all expired and invalid (except roots where the signature algorithm doesn't matter at all). In 1.3 the certifcates are now encrypted, but if you are on-path you can actively make a test connection to the same server with the same parameters and you're pretty much guaranteed to get the same certificates, which you can look at. For that matter many certs from public CAs are now in the public transparency logs and you can look there -- although if a server/domain has multiple current public certs in the logs you don't know which one(s) is(are) actually used.
Those said, regarding your other Q I have no idea whether squid in particular can do any or all of this, or could resonably be modified to do so.
Lastly, to be clear, although this will detect some cases where a connection is insecure, the lack of an identified weak primitive in a connection does NOT mean it is secure. Except for the intentionally-broken export suites and long obsolete single-DES, and a few cases of certs signed using MD5, I've heard no credible allegations of real-world breaks of SSL/TLS connections because of weak primitives (not even RC4). Instead the breaks are due to bad parameters or keys (sometimes visibly so, i.e. too small, sometimes not) or protocol or implementation flaws, or not the connection at all but rather an endpoint. Plus not all connections even between the same pair of endpoints are the same, and the existence of some apparently-good connection(s) does not prevent the past, present, or future occurrence of bad one(s).