SSL3 error when requesting connection using TLS 1.2

Question

I've come across several hosts that throw SSL3 handshake errors even though I explicitly request TLS 1.2. Why is this? Am I using the openssl client wrong?

$ openssl s_client -tls1_2 -connect i-d-images.vice.com:443
CONNECTED(00000003)
140735150146384:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
140735150146384:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1444078671
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Answer 1

In SSL/TLS, the client does not request a specific protocol version; the client announces the maximum protocol version that it supports, and then the server chooses the protocol version that will be used. Your client does not tell "let's use TLS 1.2"; it says "I know up to TLS 1.2".

A client may have its own extra requirements, but there is no room to state them in the ClientHello message. If the client wants to do TLS 1.2 only, then he must announce "up to TLS 1.2" in its ClientHello, and also close the connection if the server responds with a message that says anything else than "let's do TLS 1.2". In your case, things did not even reach that point: the server responded with a fatal alert 40 ("handshake_failure", see the standard). As @dave_thompson_085 points out, this is due to a lack of SNI: this is an extension by which the client documents in its ClientHello message the name of the target server. SNI is needed by some servers because they host several SSL-enabled sites on the same IP address, and need that parameter to know which certificate they should use. The command-line tool openssl s_client can send an SNI with an explicit -servername option.

As @Steffen explained, SSL 3.0 and all TLS versions are quite similar and use the same record format (at least in the early stage of the handshake) so OpenSSL tends to reuse the same functions. Note that since the server does not respond with a ServerHello at all, the protocol version is not yet chosen, and SSL 3.0 is still, at least conceptually, a possibility at that early point of the handshake.

Answer 2

ssl3_read_bytes and ssl3_writes_bytes deal with SSL3-style frames. These are the same with later versions, i.e. TLS1.x. Thus the same functions get used, even though their names might suggest a different thing. There is no specific tls1_read_bytes function or similar.