> On Aug 9, 2016, at 2:19 PM, Steve Malenfant <[email protected]> wrote: > > 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
This comment is a little misleading (mea culpa) but the paragraph gives the full context. What it is trying to say is that the dest_ip is only examined if no SNI match was made. Certificate matching logically works from most to least specific, so a SNI match has precedence over a wildcard SNI match, which has precedence over an IP address match, which has precedence over dest_ip=*. https://docs.trafficserver.apache.org/en/latest/admin-guide/files/ssl_multicert.config.en.html#certificate-selection > > > > 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 > > > > > > > > > >
