Chasing down this same fun ( ) with https://s3.amazonaws.com/
Can anyone else confirm?
Reason: error:00000000:lib(0):func(0):reason(0)SL error at server handshake:state 25:Application response 500 handshakefailed
My dev proxy with legacy handshake enabled connects fine, but without it, handshake failed.
I'd love to go beat on Amazon to tell them their security house isn't as in order as they'd like (if these legacy handshakes open attack surface), but when doing so I'd love to make the case to them in terms of RFC's CVE's curl and openssl s_client as possible.
Anyone happen to know how to reproduce the handshake failure on the command line?
Is there an opportunity for Amazon to fix something here?
So... for those in the know on this, is it the "Peer signing digest: SHA1" that's offensive to web gateway policy that has legacy signatures disabled?
# openssl s_client -debug -connect s3.amazonaws.com:443
write to 0xc21730 [0xd07eb0] (289 bytes => 289 (0x121))
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Baltimore CA-2 G2
No client certificate CA names sent
Peer signing digest: SHA1
Server Temp Key: ECDH, P-256, 256 bits
SSL handshake has read 3140 bytes and written 415 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
No ALPN negotiated
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1475872627
Timeout : 300 (sec)
Verify return code: 0 (ok)
in this case it's the "Baltimore CyberTrust Root" certificate with a sha1 signature at the top of the chain.