With SSL Bump, Squid runs a Man-in-the-Middle attack between the client and the server; it poses as a fake server with a fake certificate when talking to the client, and as a fake client when talking to the true SSL server. Squid thus obtains all the data. If you want to see what Squid sees, then it seems that the best option would be to simply ask Squid to send you a copy. Apparently, this is at least theoretically feasible through the ICAP feature: it is a way for Squid to do just that. Antivirus software links to Squid through ICAP, and inspect both the HTTP message contents and the headers.
Otherwise, if you do not have the help of Squid, then you must understand what occurs at the SSL level. In particular, tools ssldump can decrypt captured SSL traffic only if the following conditions are all true:
- The decrypting tool is given a copy of the server private key.
- The decrypting tool supports the cryptographic algorithms used for the connection.
- The cipher suite selected by the server (based upon what the client supports and prefers) uses an RSA-based key exchange. With "DHE" cipher suites, the actual key exchange uses ephemeral Diffie-Hellman keys, and the server private key is used only for signatures; having a copy of that private key would not help here.
In your case, there are two SSL connections, one between the client and Squid, the other between Squid and the genuine server. If you have a copy of the server key, then you can concentrate on the latter, and forget everything about SSL Bump and Squid. However, in a more general case, as the sysadmin of Squid you control Squid, not the target server.
With SSL Bump, Squid generates a fake server certificate when talking to the client. If you can get a copy of the private key for that fake certificate, then you should be able to apply ssldump on the client-to-Squid connection. As described here, the tool that Squid uses to generate fake certificates is configurable, so you could use your own, which generates the certificate (e.g. with OpenSSL) and records the private key somewhere, so that a captured trace can be decrypted later on.
For the cipher suite, this seems to be doable with the Squid
https_port directive, which accepts a "cipher=" parameter. As said here, the value of that parameter is passed directly to the underlying SSL library that Squid uses, and that's OpenSSL.
See also this forum thread where someone is apparently trying to do the same thing as you.