Dave, Thanks for this information. Looks like AES128-SHA is already specified. Here's my current configuration. Anything that stands out that I should change to make an attempt at making it work? All I need right now is making it work in a close/controlled environment.
CONFIG proxy.config.ssl.server.cipher_suite STRING ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:RC4-SHA:RC4-MD5: *AES128-SHA*:AES256-SHA:DES-CBC3-SHA!SRP:!DSS:!PSK:!aNULL:!eNULL:!SSLv2 CONFIG proxy.config.ssl.SSLv2 INT 0 CONFIG proxy.config.ssl.SSLv3 INT 1 CONFIG proxy.config.ssl.TLSv1 INT 1 About the client, I don't have the control over that. But I will ask. Steve On Fri, Aug 5, 2016 at 2:34 PM, Dave Thompson <[email protected]> wrote: > 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 > > > > > > > > >
