You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Steve Malenfant <sm...@gmail.com> on 2016/07/22 13:02:52 UTC
Centos 5.8 and Traffic Server SSL
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've done what's not recommended which I enabled SSLv2/v3 (to try) and
removed the "!SSLv2" from the cypher list. I even tried using "ALL" in the
ciphers list, but nothing worked.
RC4-SHA is included in the ciphers list when I start Traffic Server.
Curl shows :
* Connected to x.x.x.x (x.x.x.x) port 443
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSLv2, Client hello (1):
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
failure
* Closing connection #0
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert
handshake failure
traffic.out logs shows :
[Jul 22 12:52:18.902] Server {0x2b2f44504700} DEBUG: (ssl.error.accept) SSL
accept returned -1, ssl_error=1, ERR_get_error=336109761
(error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher)
[Jul 22 12:52:18.902] Server {0x2b2f44504700} DEBUG: (ssl)
SSL::47482009569024:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no
shared cipher:s3_srvr.c:1352: peer address is 192.168.49.249
[Jul 22 12:52:18.902] Server {0x2b2f44504700} DEBUG:
<SSLNetVConnection.cc:972 (sslServerHandShakeEvent)> (ssl) SSL handshake
error: SSL_ERROR_SSL (1), errno=0
[Jul 22 12:52:18.902] Server {0x2b2f44504700} DEBUG:
<SSLNetVConnection.cc:1088 (sslServerHandShakeEvent)> (ssl)
SSLNetVConnection::sslServerHandShakeEvent, SSL_ERROR_SSL
Other sites I can connect to (curl -v) :
* SSLv2, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using RC4-SHA
Would appreciate some initial pointers on what I should be looking for.
Thanks,
Steve
Re: Centos 5.8 and Traffic Server SSL
Posted by James Peach <jp...@apache.org>.
> On Aug 9, 2016, at 2:19 PM, Steve Malenfant <sm...@gmail.com> 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 <sm...@gmail.com> 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 <da...@yahoo-inc.com> 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 <sm...@gmail.com> 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 <jp...@apache.org> wrote:
>
> > On Jul 22, 2016, at 11:23 PM, Steve Malenfant <sm...@gmail.com> 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 <h....@thelounge.net> 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
> >
> >
>
>
>
>
>
>
Re: Centos 5.8 and Traffic Server SSL
Posted by Dave Thompson <da...@yahoo-inc.com>.
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 <sm...@gmail.com> 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 <sm...@gmail.com> 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 <da...@yahoo-inc.com> 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 <sm...@gmail.com> 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 <jp...@apache.org> wrote:
> On Jul 22, 2016, at 11:23 PM, Steve Malenfant <sm...@gmail.com> 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 <h....@thelounge.net> 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
>
>
Re: Centos 5.8 and Traffic Server SSL
Posted by Steve Malenfant <sm...@gmail.com>.
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 <sm...@gmail.com>
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 <da...@yahoo-inc.com> 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 <sm...@gmail.com>
>> 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 <jp...@apache.org> wrote:
>>
>>
>> > On Jul 22, 2016, at 11:23 PM, Steve Malenfant <sm...@gmail.com>
>> 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 <h....@thelounge.net>
>> 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
>> >
>> >
>>
>>
>>
>>
>>
>
Re: Centos 5.8 and Traffic Server SSL
Posted by Dave Thompson <da...@yahoo-inc.com>.
I see these four ciphers in common between your client-hello request and your server config:
RC4-SHA
RC4-MD5
AES128-SHA
AES256-SHA
So it seems the error message may be misleading. Looking closer at the trace, it's presenting an old backwards compatible SSLv2 style client-hello, with a record layer that says it can do TLS 1.0. The response your client had from "Another https site" looks like a successful transition to TLSv1.0 as final version. Not sure this helps you much. Perhaps testing with an alternative client may shed some light, e.g. curl and then use the version flags (--sslv3, --ciphers).
On Friday, August 5, 2016 1:51 PM, Steve Malenfant <sm...@gmail.com> 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 <da...@yahoo-inc.com> 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 <sm...@gmail.com> 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 <jp...@apache.org> wrote:
> On Jul 22, 2016, at 11:23 PM, Steve Malenfant <sm...@gmail.com> 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 <h....@thelounge.net> 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
>
>
Re: Centos 5.8 and Traffic Server SSL
Posted by Steve Malenfant <sm...@gmail.com>.
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 <da...@yahoo-inc.com> 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 <sm...@gmail.com>
> 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 <jp...@apache.org> wrote:
>
>
> > On Jul 22, 2016, at 11:23 PM, Steve Malenfant <sm...@gmail.com>
> 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 <h....@thelounge.net>
> 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
> >
> >
>
>
>
>
>
Re: Centos 5.8 and Traffic Server SSL
Posted by Dave Thompson <da...@yahoo-inc.com>.
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 <sm...@gmail.com> 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 <jp...@apache.org> wrote:
> On Jul 22, 2016, at 11:23 PM, Steve Malenfant <sm...@gmail.com> 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 <h....@thelounge.net> 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
>
>
Re: Centos 5.8 and Traffic Server SSL
Posted by Steve Malenfant <sm...@gmail.com>.
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 <jp...@apache.org> wrote:
>
> > On Jul 22, 2016, at 11:23 PM, Steve Malenfant <sm...@gmail.com>
> 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 <h....@thelounge.net>
> 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
> >
> >
>
>
Re: Centos 5.8 and Traffic Server SSL
Posted by James Peach <jp...@apache.org>.
> On Jul 22, 2016, at 11:23 PM, Steve Malenfant <sm...@gmail.com> 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 <h....@thelounge.net> 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
>
>
Re: Centos 5.8 and Traffic Server SSL
Posted by Steve Malenfant <sm...@gmail.com>.
So there is absolutely no way I can connect a Centos 5 client to ATS/https?
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 <h....@thelounge.net>
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
>
>
Re: Centos 5.8 and Traffic Server SSL
Posted by Reindl Harald <h....@thelounge.net>.
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