OpenSSL naturally will prefer newer MACs for otherwise-equivalent cipher suites. For example, the lengthy openssl ciphers -v output for your cipher string starts with:
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
Of course, TLS will only use cipher suites supported mutually by both the server and client, and neither Chrome nor Firefox support HMAC-SHA256 cipher suites. Since HMAC-SHA1 (and even HMAC-MD5) are still considered secure, I believe their developers (and those of NSS, the TLS library they both use) are skeptical of wasting developer effort and TLS handshake size adding new, unnecessary, and backwards-incompatible cipher suites.
Look at, for example, Chrome 33's supported cipher suites in order of preference:
- ChaCha20-Poly1305,
- AES-128-GCM,
- AES-256-CBC with HMAC-SHA1,
- RC4 (ugh) and AES-128-CBC with HMAC-SHA1, ...
OpenSSL doesn't support ChaCha20-Poly1305. If yours doesn't support AES-GCM either (???) and uses an RSA certificate, ECDHE-RSA-AES256-SHA is naturally the cipher suite Chrome will use. (Firefox 29 would use ECDHE-RSA-AES128-SHA.)
(The "SHA-256" cipher suites you've seen being used on other websites are presumably ChaCha20-Poly1305 or AES-128-GCM, which are AEADs that do not make use of HMAC, but whose cipher suites use SHA-256 in the PRFPRF.)
