How did SSLv3 get AES?

Question

IANA maintains a registry of TLS cipher suites at TLS Parameters. TLS provides TLS_RSA_WITH_AES_128_CBC_SHA, its value is {0x00, 0x2f}, and its available in TLS 1.0 and above. The AES cipher suites were added to TLS with RFC 3268, AES Ciphersuites for TLS in 2002.

However, AES cipher suites were not added to SSLv3 because SSLv3 is not under the control of the IETF. From RFC 5746, Section 4.5:

While SSLv3 is not a protocol under IETF change control (see [SSLv3]), it was the original basis for TLS and most TLS implementations also support SSLv3.

OpenSSL provides TLS_RSA_WITH_AES_128_CBC_SHA via cipher AES128-SHA (see OpenSSL's docs on ciphers(1)). AES128-SHA works with SSLv3 via s_client, and a quick Wireshark trace shows cipher suite {0x00, 0x2f} is used.

$ openssl s_client -ssl3 -connect google.com:443 -cipher "AES128-SHA"
CONNECTED(00000003)
...
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
...
SSL-Session:
    Protocol  : SSLv3
    Cipher    : AES128-SHA
...

I cannot find a reference where the AES cipher suites are valid in SSLv3. I looked in the draft The SSL Protocol Version 3.0 from 1996, RFC 6101, The Secure Sockets Layer (SSL) Protocol Version 3.0 from 2011, and RFC 3268, AES Ciphersuites for TLS from 2002. I even searched IETF Tools for AES and SSL.

Where are the AES ciphers suites covered for the SSLv3 protocol?

score 9 · Accepted Answer · edited Oct 07 '21 at 06:47

SSL 3.0 is not a standard. Realistically, it is "what Netscape was doing at that time". When the protocol was turned into a standard, it became RFC 2246, aka "TLS 1.0".

The original document which the TLS authors used as source was later on (much later on) put in the RFC format and became RFC 6101, which has category "Historic". Historic RFC are quite low on the standards ladder; they are even below the "Informational" RFC. Before publication of that RFC, people intent on writing an SSL library would first implement TLS 1.0 as per the RFC, then wade through OpenSSL's source code and make interoperability tests with existing implementations to also offer SSLv3.

Since SSLv3 is a de facto but not de jure standard, you will not find a RFC which specifies the standard way of doing AES with SSL 3.0; by definition, there cannot be such a standard. At best, one may imagine an "Historic" RFC which would document the common practice, which is namely direct usage of RFC 3268. SSL 3.0 is very similar to TLS 1.0, so the backport of AES cipher suites from TLS 1.0 to SSL 3.0 is not ambiguous; as someone who already did that (several times !), I can confirm that getting AES support "right" in SSL 3.0 is not hard (where "right" means: "works with existing SSL clients and servers").

Interestingly MS's SChannel don't support it: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx — Yuhong Bao, Dec 27 '14 at 06:11
Actually, SSLv3 was published in Internet-Drafts which most people that implemented SSLv3 used. — Yuhong Bao, Dec 27 '14 at 06:13

How did SSLv3 get AES?

1 Answers1