Using the openssl command, how can I tell if it's using TLS 1.0?
TL;TR: It is far from trivial to verify from the client that a server is not supporting TLS 1.0. You can be sure that the server supports TLS 1.0 if you get a successful connection with TLS 1.0. But you cannot be sure that the server does not support TLS 1.0 if this attempt fails.
As you already realized the information given in the link you cite are at least partly wrong. Also, they are incomplete. Checking if a server has really TLS 1.0 disabled is not that simple. To understand what need to be checked to be really sure it is better to have at least a basic understanding of how the TLS-Handshake works. Note that most of what I say here is also true for SSL, which is mainly the earlier name for the same protocol family now known as TLS.
Initially, the client needs to create a TCP connection to the server. This has nothing to do with TLS itself yet. And already if the TCP connection succeeds you will get CONNECTED(00000003). If you don't get this CONNECTED then the server might be down or might not be reachable from your site, for example because a firewall is blocking the access. Thus, not getting the CONNECTED says nothing about the ability of the server to support TLS 1.0.
After the TCP connection is created the TLS part begins. In the simplest case the client sends at the beginning of the TLS handshake inside the ClientHello message the best TLS version it can and the ciphers it supports. The server replies with the best SSL/TLS protocol it supports which is equal or lower to the protocol version offered by the client. And the server picks the common cipher based on what the client offers and and what is configured to be acceptable for the server. In your specific case the client offers TLS 1.0 as the best protocol (due to the -tls1 option) and the default cipher set. The handshake will fail if the server does not support TLS 1.0 or lower OR if the server does not support any of the ciphers offered by the client. Because of the last part it is possible that the server fails with your specific client even if the server has TLS 1.0 enabled because the server does not like the ciphers offered by the client.
And it gets more complex. It is common that servers support multiple certificates on the same IP address today. This is done by including the target hostname using the SNI TLS extension inside the ClientHello at the start of the TLS handshake. If there is no SNI extension or if the extension does not match any configured hostname the server will usually either send some default certificate or abort the handshake. Because of the last part it is possible that the server fails with your specific client even if the server has TLS 1.0 enabled because no SNI extension was used or it was used with the wrong hostname. openssl s_client will not use SNI by default so your attempt might simply have failed just because of a missing SNI extension. You have to use the -servername option for this and of course you need to use a hostname properly configured at the server with this option.
And so far we dealt only with sane TLS stacks and a direct connection to the server. If the TLS stack is broken or if there is some broken middlebox in between (like load balancers, firewalls etc) they might make the handshake fail accidentally or on purpose even though the server supports TLS 1.0. And if you have some SSL termination in front of your server (some firewalls, load balancers or a CDN) you will not even test the properties of the server but of the system in front of it.
In other words: if you get a successful TLS 1.0 connection to the server you can be sure that the server or some SSL terminator in front of it supports TLS 1.0. If the TLS 1.0 connection fails instead it does not mean for sure that the server does not support TLS 1.0.
Although these tools do not directly answer your specific question, they may provide the results you are looking for. If you have an Internet connection, try some of these:
- https://www.htbridge.com/ssl/
- https://www.ssllabs.com/ssltest/
- https://www.digicert.com/help/
If no Internet Connection try:
- https://github.com/drwetter/testssl.sh/
- https://github.com/TKCERT/testssl.sh-webfrontend
Yes that website is wrong; CONNECTED means the TCP connection succeeded but says nothing about the TLS (or hopefully not SSL) handshake. If you don't get CONNECTED but get a few lines ending with connect: errno=$n (even if the number is 0!) it means we weren't even able to attempt a handshake and thus have no information either way what the server supports.
Although you could learn to read the error messages and other info openssl puts out, the key indicator is the line beginning New, at the beginning of the last block of output (after the --- a few lines before SSL-Session:); if it shows a real protocol version and cipher the handshake succeeded, if it has (NONE) the handshake failed -- as yours does.
Note the handshake can fail for reasons other than the protocol version. If this test succeeds for 1.0, you can be sure the server does support 1.0, but if this test fails it doesn't definitely prove the server doesn't support 1.0. You'll need to actually learn about TLS to distinguish those. As Steffen posted at much greater length while I was writing this -- but I decided my paras 2 and 4 may still help.
FWIW also note testing for SSLv2 using only s_client -ssl2 is not valid on releases 1.0.0 up where the default cipherlist prevents SSLv2 connection even on servers that support SSLv2. However, anyone still worrying today about SSLv2 on a real (not test-lab or museum) server is in deep trouble.