What is PCT_SSL_CIPHER_TYPE_1ST_HALF?

Question

I'm writing a tool to do security posture assessments of SSL/TLS services, and ran into an interesting result. I ran through all defined cipher suites to test which could be negotiated (like sslscan does) and found that an unusual PCT-related cipher suite, PCT_SSL_CIPHER_TYPE_1ST_HALF (0x830004) appeared to be accepted by a number of sites.

I'm aware of PCT as a precursor-of-sorts to TLS, alongside early SSL implementations, but I can't find any information as to what PCT_SSL_CIPHER_TYPE_1ST_HALF is, or why modern SSL/TLS stacks would ever negotiate it successfully.

What is this suite? Why can I negotiate it?

Answer 1

As usual, I ask a question after a couple of days of research, then immediately realise the answer: I'm doing it wrong.

My definitions included the following "suites":

SSL2_RC4_128_WITH_MD5   0x010080    
SSL2_RC4_128_EXPORT40_WITH_MD5  0x020080    
SSL2_RC2_CBC_128_CBC_WITH_MD5   0x030080    
SSL2_RC2_CBC_128_CBC_WITH_MD5   0x040080    
SSL2_IDEA_128_CBC_WITH_MD5  0x050080    
SSL2_DES_64_CBC_WITH_MD5    0x060040    
SSL2_DES_192_EDE3_CBC_WITH_MD5  0x0700C0    
SSL2_RC4_64_WITH_MD5    0x080080    
CT_SSL_CERT_TYPE    0x800001    
PCT_SSL_CERT_TYPE   0x800003    
PCT_SSL_HASH_TYPE   0x810001    
PCT_SSL_HASH_TYPE   0x810003    
PCT_SSL_EXCH_TYPE   0x820001    
PCT_SSL_CIPHER_TYPE_1ST_HALF    0x830004    
PCT_SSL_CIPHER_TYPE_2ND_HALF_40     0x842840    
PCT_SSL_CIPHER_TYPE_2ND_HALF_128    0x848040
PCT_SSL_COMPAT  0x8F8001    

TLS has a cipher suite specifier length of 16 bits. My code, when given these 24-bit identifiers, ignores the high 8 bits. This means I'm really scanning for 0x0080 a few times, 0x0040, 0x00C0, 0x0001, 0x0003, 0x0004 (*), 0x2840, 0x8040, and 0x8001.

Since 0x0004 is RSA_WITH_RC4_128_MD5, and the target server supports that suite, my code was incorrectly reporting that PCT_SSL_CIPHER_TYPE_1ST_HALF was enabled. It just happened to coincide. Other values did not align with enabled cipher suites, so that's the only one that cropped up.

I've now removed these definitions since they're erroneous for SSL/TLS.

Silly me!