Unable to negotiate acceptable set of security parameters

[cyberduck]

2fff14b created the issue

We've noticed an increase in "inoperability failures" when connecting to secure webdav using P12's generated as part of our 2FA requirement when connecting to our SaaS based web platform. The login process never transfers from the certificate selection to allowing access to the key chain.

We've tracked it by trial/error to a change somewhere between version 4.7.3 (works) and 4.8.1 (failures)

• Affected Systems: MBP 2.4/Core i5 OSX 10.9.5 & MBP 2.7 Core i5 OSX 10.11.4

• Working versions: 4.5 - 4.7.3.
• Non-working version: First non-working version 4.8.1 (4.8.1.19040.zip)
• Windows machine has worked through all versions up to and including 4.9

Same remote webdav host/path and credentials and P12's used in all tests.

Here are the OpenSSL commands used to create the P12 (if this helps at all...)

openssl req -new -sha256 -newkey rsa:1024 -nodes -out client.req -keyout client.key
openssl x509 -CA client.net_01.crt -CAkey client.net_011.key -CAserial client.net_011.srl -req -in client.req -out client.pem -days 365
openssl pkcs12 -export -in client.pem -inkey client.key -certfile client.crt -name "client" -out client.p12

I did notice that 4.8.1 was the first to have this:
[Bugfix] Restore compatibility with OS X 10.7 - 10.9 (Mac)
but unsure if that excludes versions 10.9.5 and higher... couldn't find a trac number to research further.

---

Attachments

• Error Messsage Steps.docx (1173.0 KiB)
• Handshake Failure.png (78.6 KiB)

[cyberduck]

@dkocher commented

Can you please post the error message displayed.

[cyberduck]

2fff14b commented

Here are the steps - including identical P12 certs, environments and credentials.

[cyberduck]

2fff14b commented

Definitely doesn't work across multiple machines. I'd be interested to try the steps that work after version 4.7. Appreciate the time.

[cyberduck]

@dkocher commented

[cyberduck]

@dkocher commented

Can you please share the hostname of the server. This will allow us to debug the SSL negotiation.

[cyberduck]

2fff14b commented

Happy to provide, but would rather not do it on a publicly accessable site - shoot me an email? chouser@pfsweb.com

[cyberduck]

@dkocher commented

osaka:~ dkocher$ nmap --script ssl-enum-ciphers -p 443 ----------.demandware.net

Starting Nmap 7.01 ( https://nmap.org ) at 2016-04-19 11:21 CEST
Nmap scan report for ----------.demandware.net (66.179.158.204)
Host is up (0.33s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - D
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 1024) - D
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Weak certificate signature: SHA1
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - D
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 1024) - D
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Weak certificate signature: SHA1
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - D
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 1024) - D
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Weak certificate signature: SHA1
|_  least strength: D

Nmap done: 1 IP address (1 host up) scanned in 18.09 seconds

[cyberduck]

@dkocher commented

osaka:~ dkocher$ openssl s_client -connect ----------.demandware.net:443 -servername ----------.demandware.net
CONNECTED(00000003)
depth=0 /C=US/ST=FLORIDA/L=Miramar/O=Elizabeth Arden, Inc./OU=NA/CN=----------.demandware.net/emailAddress=dwsupport_elizabetharden@pfsweb.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=FLORIDA/L=Miramar/O=Elizabeth Arden, Inc./OU=NA/CN=----------.demandware.net/emailAddress=dwsupport_elizabetharden@pfsweb.com
verify return:1
20883:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.40.2/src/ssl/s3_pkt.c:1145:SSL alert number 40
20883:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.40.2/src/ssl/s23_lib.c:185:

[cyberduck]

@dkocher commented

Looks like a server configuration issue. Chrome.app also complains with The client and server don't support a common SSL protocol version or cipher suite. This is likely to be caused when the server needs RC4, which is no longer considered secure..

[cyberduck]

@ylangisc commented

I'm now able to reproduce the issue but the exact reason is not clear yet. We need some more time to investigate.

[cyberduck]

@dkocher commented

In 3487a54.

[cyberduck]

@dkocher commented

#9500 closed as duplicate.

[cyberduck]

@dkocher commented

Fix use of EC algorithms on Windows in d90f59f.