Steve, First off, I'd suggest turning off the SSLv2. It doesn't work with
most modern browers today, and it has many vulnerabilities, the worst of which
can compromise all of your other servers that share a certificate (see DROWN)
even if they don't have SSLv2 turned on. If I recall correctly, newer
version of ATS actually require recompile to turn it on.
No shared ciphers, means that the client and server can't agree on a cipher
suite. While your client cipher suite looks really outdated and has many
ciphers that shouldn't be used for several reasons (e.g. EXPORT), the old AES
version you have listed is often kept around for backward compatibility. This
one TLS_RSA_WITH_AES_128_CBC_SHA, can be specified in your records.conf as
"AES128-SHA"
So you can have something like:CONFIG proxy.config.ssl.server.cipher_suite
STRING AES128-SHA
AES128-SHA didn't exist in SSLv2 days, so I'm guess your client will at least
handle SSLv3 which can be turned on by:
CONFIG proxy.config.ssl.SSLv3 INT 1
Note SSLv3 has many issues too. If you can get away with upgrading your
client, I'd suggest turning off SSLv3. Though seeing as your client cipher
list isn't presenting a single cipher that existed after SSLv3, I wouldn't be
surprised if it's capped.
Dave
On Friday, August 5, 2016 12:55 PM, Steve Malenfant <[email protected]>
wrote:
Here's what the client is sending and what the ATS server replies with. Then a
response from a working https site (Was the same exact request...)
Secure Sockets Layer
SSLv2 Record Layer: Client Hello [Version: SSL 2.0 (0x0002)]
Length: 103 Handshake Message Type: Client Hello (1) Version: TLS
1.0 (0x0301) Cipher Spec Length: 78 Session ID Length: 0
Challenge Length: 16 Cipher Specs (26 specs) Cipher Spec:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x000039) Cipher Spec:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x000038) Cipher Spec:
TLS_RSA_WITH_AES_256_CBC_SHA (0x000035) Cipher Spec:
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x000016) Cipher Spec:
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013) Cipher Spec:
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a) Cipher Spec:
SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0) Cipher Spec:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x000033) Cipher Spec:
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x000032) Cipher Spec:
TLS_RSA_WITH_AES_128_CBC_SHA (0x00002f) Cipher Spec:
SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080) Cipher Spec:
TLS_RSA_WITH_RC4_128_SHA (0x000005) Cipher Spec:
TLS_RSA_WITH_RC4_128_MD5 (0x000004) Cipher Spec:
SSL2_RC4_128_WITH_MD5 (0x010080) Cipher Spec:
TLS_DHE_RSA_WITH_DES_CBC_SHA (0x000015) Cipher Spec:
TLS_DHE_DSS_WITH_DES_CBC_SHA (0x000012) Cipher Spec:
TLS_RSA_WITH_DES_CBC_SHA (0x000009) Cipher Spec:
SSL2_DES_64_CBC_WITH_MD5 (0x060040) Cipher Spec:
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000014) Cipher Spec:
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x000011) Cipher Spec:
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000008) Cipher Spec:
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x000006) Cipher Spec:
SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080) Cipher Spec:
TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003) Cipher Spec:
SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080) Cipher Spec:
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x0000ff) Challenge
Secure Sockets Layer TLSv1 Record Layer: Alert (Level: Fatal, Description:
Handshake Failure) Content Type: Alert (21) Version: TLS 1.0
(0x0301) Length: 2 Alert Message Level: Fatal (2)
Description: Handshake Failure (40)
This is the response from Another https site :
Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Server Hello Content Type:
Handshake (22) Version: TLS 1.0 (0x0301) Length: 81
Handshake Protocol: Server Hello TLSv1 Record Layer: Handshake Protocol:
Certificate Content Type: Handshake (22) Version: TLS 1.0
(0x0301) Length: 973 Handshake Protocol: Certificate TLSv1
Record Layer: Handshake Protocol: Server Hello Done
On Thu, Jul 28, 2016 at 5:59 AM, James Peach <[email protected]> wrote:
> On Jul 22, 2016, at 11:23 PM, Steve Malenfant <[email protected]> wrote:
>
> So there is absolutely no way I can connect a Centos 5 client to ATS/https?
I don’t know why this wouldn’t work, but it can be difficult to debug what is
hindering the negotiation. I’d start attacking this by taking a packet trace of
a working TLS session to see what is negotiating successfully. That will give
you a target for what you have to do on the ATS side.
>
>
> All my tests were on internal networks in the lab. This would eventually
> needs to connect on external networks (on ACLs), but this is simply trying to
> run a proof of concept.
>
> Thanks,
>
>
> On Fri, Jul 22, 2016 at 9:16 AM, Reindl Harald <[email protected]> wrote:
>
>
> Am 22.07.2016 um 15:02 schrieb Steve Malenfant:
> I'm trying to connect and older proprietary system running on Centos 5.8
> to an internal CDN running ATS 5.3.2 via https. Somehow I can connect to
> a bunch of different sites, but not to ATS.
>
> I don't know much about SSL, but I can't get pass initial handshake
> which is saying there is "no shared ciphers"
>
> i fear the TLS support in CentOS 5 is a dead road these days
> CentOS6 has acceptable backports - but CentOS5 - no
>
> why does the CentOS5 sit outside and connect via TLS to internal machines
> running ATS? normally you are doing things the other way - having internal
> nodes without TLS and use ATS for SSL offloading so that oldm oputdated stuff
> is not exposed to the internet
>
>
