I've added the "dest_ip=*" and this worked with the older client. From the description on the page, seems like SNI is required, but if SNI is not presented it can be used as a fallback. That was a shot in the dark, but I believe I can probably conduct my initial testing.
Any comments? dest_ip=ADDRESS (optional)The IP (v4 or v6) address that the certificate should be presented on. This is now only used as a fallback in the case that the TLS SubjectNameIndication extension is not supported On Fri, Aug 5, 2016 at 2:51 PM, Steve Malenfant <[email protected]> wrote: > 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 >> > >> > >> >> >> >> >> >
