Ah yes, I see the default comments in the ssl_multicert.config regarding
dest_ip.
Yep makes sense. SSLv3 protocol doesn't support SNI, so one needs to have
dest_ip=* to define the default (and required) server certificate and private
key that will be used in the SSL transaction.
On Tuesday, August 9, 2016 4:20 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
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:!SSLv2CONFIG
proxy.config.ssl.SSLv2 INT 0CONFIG proxy.config.ssl.SSLv3 INT 1CONFIG
proxy.config.ssl.TLSv1 INT 1About 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_S HA (0x000039) Cipher Spec:
TLS_DHE_DSS_WITH_AES_256_CBC_S HA (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_S HA (0x000033) Cipher Spec:
TLS_DHE_DSS_WITH_AES_128_CBC_S HA (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_S CSV (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
>
>
