I haven't used Shibboleth for a while, so I'm not sure if the following is always the case, but here is how I've used Shibboleth in the past.
The SP makes a (signed) SAML request to the IdP, which is propagated between the two by the user's browser. The IdP gives a signed SAML response, not necessarily encrypted, with an identifier. Upon reception, the SP makes a attribute request directly to the IdP.
This back-end connection is usually done via HTTPS and the connection is therefore encrypted. It doesn't go at all via the user's browser, but the SP becomes a direct client to the IdP. Using message-level encryption on top of SSL/TLS here wouldn't add much, if the SP is properly authenticated of course, this can be done using client-certificate authentication (configured in the SP using CredentialResolver
IIRC).
This is represented in steps 6 and 7 in this diagram (UK Federation).
There may be slight differences in the configuration of the Attribute Service (usually run on the IdP and queried by the SP) between Shibboleth 1.x and Shibboleth 2.x. These attribute services are configured along with the other IdP settings as part of the federation metadata given to the SPs.
As far as I'm aware, this mechanism is one of the specificities of Shibboleth, compared with other SAML-based systems.