Why is the communication protocol SSLv3 being used?

Question

This is the first time I have had to delve down to the depths of network traces, so please excuse my ignorance. We have a working interface between one of our systems and an external company. The other day it stopped working and after a bit of investigation we discovered that they had turned off support for SSLv3. This seems to be a wise thing to do. However it broke the communications so we had to get them to turn it back on. We are using SAP on our end. All the research I have done indicates that we should support TLS. So it seemed strange that SSL v3 was being used after all. I ran a wireshark trace to hopefully tell me what was going on. Below is the extract. But I don’t know how to interpret it. It says the Handshake protocol is TLSv1, but then there is a mention of Version SSL 3.0. Does that mean it is using SSL 3.0 . If that is the case, how do I found out why isn’t it using TLS?

Frame 4: 114 bytes on wire (912 bits), 114 bytes captured (912 bits) on interface 0
Ethernet II, Src: Vmware_9e:4a:78 (00:50:56:9e:4a:78), Dst: All-HSRP-routers_01 (00:00:0c:07:ac:01)
Internet Protocol Version 4, Src: 10.6.243.200, Dst: 203.27.124.106
Transmission Control Protocol, Src Port: 61460 (61460), Dst Port: 443 (443), Seq: 1, Ack: 1, Len: 60
Secure Sockets Layer
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: SSL 3.0 (0x0300)
        Length: 55
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 51
            Version: TLS 1.0 (0x0301)
            Random
            Session ID Length: 0
            Cipher Suites Length: 12
            Cipher Suites (6 suites)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
                Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
            Compression Methods Length: 1
            Compression Methods (1 method)

regards Tony Lewis

Answer 1

A generic answer maybe:

SSL was the original name, TLS took over at some point, and the numbering was both restarted and changed. So the last SSL (3.0) has evolved into TLS v1.0. So counter-intuitively, TLS v1.2 is newer (more advanced) than SSL 3.0.
the dissectors follow the evolution of the protocols, but as many protocol fields are identical for SSL and TLS, you can see "Version: SSL 3.0 (0x0300)" in a TLSv1 packet because the dissector for SSL1.0 through to TLSv1.2 is (most likely, I'm not a core developer) the very same code. The packet whose text dissection you've posted seems to still be TLSv1.0, however in later phase of the client/server negotiation, the connection may have become a pure SSL 3.0.
as time goes, older protocols become obsolete, which is best seen in the security area where new vulnerabilities are discovered, so use of older versions of this SSL/TLS family (all SSL versions and TLSv1.0 included) is discouraged as they are not considered safe any more.

So re-enabling of TLSv1.0 (or even SSL3.0) at the external company side should be considered only a workaround. The solution should be to implement (activate?) support of TLS1.2 at your end.

Analysis of the whole capture from the negotiation phase can tell you what versions of TLS the external company's server currently offers, and where the negotiation actually ends (SSL 3.0 or TLSv1.0) while the workaround is in place.

The only answer to the "why" which Wireshark can give you is "because this side of the conversation has asked for that, and the other side has agreed". But the answer to "why this side has asked for that" is something Wireshark cannot tell you. To get this answer, you have to talk to the administrator and/or developer of that side.

Answer 2

The two versions you see are for different purposes. SSL 3.0 and TLS 1.0 up to 1.2 have a record layer containing a version (SSL 3.0 in your case) which roughtly advertises the minimum supported version. The version included in the Client Hello message (TLS 1.0 in your case) is the highest version supported by the client.

According to your capture the client indeed supports TLS 1.0. Its set of supported cipher suites is however not that strong. Your external company might require more secure ciphers. See https://wiki.mozilla.org/Security/Server_Side_TLS for what is considered acceptable.

Misbehaved servers will immediately reset the connection if they do not understand/accept the Client Hello. Good implementations will however send an "Alert" containing the reason why the connection fails. Possible reasons include handshake_failure and insufficient_security. Their meanings can be found in RFC 5246 (TLS 1.2) - 7.2.2. Error Alerts.