o curl não consegue recuperar o conteúdo HTTPS: erro: 14094410: rotinas SSL: ssl3_read_bytes: falha de handshake de alerta sslv3

Question

Estou tentando acessar o site https://www.lawsociety.com.au com o curl no Windows 10 e no Ubuntu 16.04. Ele funciona no Ubuntu, mas falha no Windows com a mensagem error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure . Não tenho certeza do que está errado e como corrigi-lo.

Aqui está a saída de curvatura na máquina Windows:

> curl -i -v -I https://www.lawsociety.com.au
* Rebuilt URL to: https://www.lawsociety.com.au/
*   Trying 125.7.104.7...
* TCP_NODELAY set
* Connected to www.lawsociety.com.au (125.7.104.7) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: D:\dev\curl\bin\curl-ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS alert, Server hello (2):
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* stopped the pause stream!
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

versão curl:

curl 7.57.0 (x86_64-pc-win32) libcurl/7.57.0 OpenSSL/1.1.0g (WinSSL) zlib/1.2.11 WinIDN libssh2/1.8.0 nghttp2/1.28.0
Release-Date: 2017-11-29
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 HTTPS-proxy MultiSSL    

O mesmo comando na caixa do Ubuntu:

$ curl -I -v https://www.lawsociety.com.au
* Rebuilt URL to: https://www.lawsociety.com.au/
*   Trying 125.7.104.7...
* Connected to www.lawsociety.com.au (125.7.104.7) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 594 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.0 / RSA_3DES_EDE_CBC_SHA1
*        server certificate verification OK
*        server certificate status verification SKIPPED
*        common name: *.lawsociety.com.au (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=AU,postalCode=2000,ST=NSW,L=Sydney,street=170 Phillip Street,O=THE LAW SOCIETY OF NEW SOUTH WALES,OU=PremiumSSL Wildcard,CN=*.lawsociety.com.au
*        start date: Fri, 17 Mar 2017 00:00:00 GMT
*        expire date: Mon, 16 Apr 2018 23:59:59 GMT
*        issuer: C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Organization Validation Secure Server CA
*        compression: NULL
* ALPN, server did not agree to a protocol
> HEAD / HTTP/1.1
> Host: www.lawsociety.com.au
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Tue, 26 Dec 2017 09:04:02 GMT
Date: Tue, 26 Dec 2017 09:04:02 GMT
< Server: Oracle-Application-Server-11g
Server: Oracle-Application-Server-11g
< Cache-Control: no-cache
Cache-Control: no-cache
< Content-Length: 36272
Content-Length: 36272
< Set-Cookie: JSESSIONID=kGs3hCQCW7FPhQ2Lh0JvKn9JvXhhHCK2GQKXvLps308Ww1D70pMp!1826685759; path=/; HttpOnly
Set-Cookie: JSESSIONID=kGs3hCQCW7FPhQ2Lh0JvKn9JvXhhHCK2GQKXvLps308Ww1D70pMp!1826685759; path=/; HttpOnly
< X-ORACLE-DMS-ECID: 005OJeGQSZb9xWGayxQ_MG0007Z60000EU
X-ORACLE-DMS-ECID: 005OJeGQSZb9xWGayxQ_MG0007Z60000EU
< X-Powered-By: Servlet/2.5 JSP/2.1
X-Powered-By: Servlet/2.5 JSP/2.1
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8

<
* Connection #0 to host www.lawsociety.com.au left intact

Eu tentei o comando openssl s_client no Windows:

> openssl s_client -connect www.lawsociety.com.au:443
CONNECTED(00000224)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:/C=AU/postalCode=2000/ST=NSW/L=Sydney/street=170 Phillip Street/O=THE LAW SOCIETY OF NEW SOUTH WALES/OU=PremiumSSL Wildcard/CN=*.lawsociety.com.au
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
... <removed to save space> ...
-----END CERTIFICATE-----
subject=/C=AU/postalCode=2000/ST=NSW/L=Sydney/street=170 Phillip Street/O=THE LAW SOCIETY OF NEW SOUTH WALES/OU=PremiumSSL Wildcard/CN=*.lawsociety.com.au
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 5683 bytes and written 621 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 8198FE887E4FC12D68E2388D4C052ABF
    Session-ID-ctx:
    Master-Key: 93688C15A75E3E9F596AF96DFF72B557AD28A3FEF8764401CBD12D1F432EAF4D216595D74338AF24498AB29FF5ABE759
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1514278771
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

Portanto, a conexão parece estar bem. Abrir o URL em um navegador também funciona bem.

O que estou perdendo?

UPDATE

1. Um dos possíveis problemas é que o site está usando códigos RC4-SHA desatualizados. Tentei ativá-lo explicitamente com curl, mas o curl rejeita:

> curl -i -v -I --ciphers "RC4-SHA" https://www.lawsociety.com.au
* Rebuilt URL to: https://www.lawsociety.com.au/
*   Trying 125.7.104.7...
* TCP_NODELAY set
* Connected to www.lawsociety.com.au (125.7.104.7) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* failed setting cipher list: RC4-SHA
* Closing connection 0
curl: (59) failed setting cipher list: RC4-SHA

2. Outro possível problema é que os certificados raiz podem não estar disponíveis. No entanto, o curl vem com o pacote mais recente do CA da Mozilla ( curl-ca-bundle.crt ), portanto, acredito que ele esteja usando certificados corretos.

Eu também copiei todos os certificados públicos da caixa Ubuntu para a máquina Windows e especifiquei o caminho do certificado para enrolar usando --capath param - isso não ajuda.

3. Apenas por completo, eu tentei com o mais recente Python 3.6.4:

import urllib.request
with urllib.request.urlopen('https://www.lawsociety.com.au/') as u:
    print(u.read())

O Python SSL deve usar as instalações do Windows para HTTPS. No entanto, falha com o mesmo erro:

ssl.SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:777)
...
During handling of the above exception, another exception occurred:
...
urllib.error.URLError: <urlopen error [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:777)>

Portanto, parece que o problema não está no certificado ausente, mas acontece em algum lugar antes. Eu não sou um especialista em SSL, então posso estar errado.

SOLUÇÃO

A causa raiz do problema é o protocolo SSL desatualizado + as cifras usadas pelo site. Para fazer o curl funcionar, eu o rebaixei para a versão que usa o OpenSSL 1.0.2, que ainda suporta cifras RC4. Depois disso tudo funciona perfeitamente.

Para quem precisa da solução Python:

import ssl
import urllib.request

ctx = ssl.SSLContext(protocol=ssl.PROTOCOL_SSLv3)
ctx.set_ciphers('SSLv3')
# alternatively, for this particular website:
#ctx.set_ciphers('RC4-SHA:RC4-MD5')

with urllib.request.urlopen('https://www.lawsociety.com.au/', context=ctx) as u:
    print(u.read())

    

Answer 1

Acredito que há dois problemas que se sobrepõem, ambos relacionados ao fato de o servidor estar aparentemente desatualizado ou, por outro lado, ter sido insanamente operado. A análise por ssllabs mostra que ele suporta apenas protocolos SSLv3 e TLSv1.0, e apenas quatro ciphersuites:

TLS_RSA_WITH_DES_CBC_SHA (0x9)   INSECURE   56
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   WEAK  112
TLS_RSA_WITH_RC4_128_MD5 (0x4)   INSECURE   128
TLS_RSA_WITH_RC4_128_SHA (0x5)   INSECURE   128

(que no esquema de nomenclatura OpenSSL são DES-CBC-SHA, DES-CBC3-SHA, RC4-MD5 e RC4-SHA).

Primeiro, como observado por SSLLabs, o servidor é "intolerante à versão"; se você enviar as versões de oferta do ClientHello acima de 1.0 em um registro com a versão 1.0 (e de outra forma aceitável) ele negocia até 1.0 como deveria *, mas se você enviar esta oferta com a versão de registro 1.1 ou 1.2, como alguns softwares fazem (mas não AFAICT algum recente OpenSSL), o servidor aborta com o alerta close_notify (o que não é correto para este estado). (*: bem, como deve ser, dado que está suportando 1.0)

Segundo, ele suporta apenas os quatro ciphersuites acima. Versões muito recentes do OpenSSL e especificamente 1.1.0g não suportam mais o DES-único (tudo) porque ele está completamente quebrado e não suporta RC4 ou DES-triplo por padrão por causa de vários vieses e o ataque genérico de aniversário ; assim, se o OpenSSL for usado, não haverá ciphersuites em comum e o servidor abortará corretamente com o handshake_failure de alerta. Mas deve ser possível ativar o RC4 e / ou o TDES, a menos que eles tenham sido configurados no momento da compilação (compilação). Percebo que sua versão do Windows mostra (WinSSL) além para OpenSSL/1.1.0g ; Eu não sei se isso significa que schannel é usado aqui (ou nada), caso em que pode ser a razão --ciphers RC4-SHA (usando o esquema de nomenclatura OpenSSL) não funcionou.

Observação em programas do Windows, especialmente 'importações' como curl e OpenSSL, normalmente não compartilham bibliotecas como no Unbuntu e na maioria dos Linux (e outros Unix). Você pode tentar openssl version no seu Windows OpenSSL para ver qual é; Aposto que não é o mais recente e se você receber o mais recente, ele exibirá o mesmo problema da linha de comando.

O Ubuntu 16.04 (suponho que o LTS?) não é de ponta e faz sentido continuar a suportar cifras que foram descontinuadas apenas recentemente.

    

Answer 2

O problema está no algoritmo e cifra de hash dos sites. Pelo menos RC4 foi declarado inseguro há muito tempo, portanto, muitos programas se recusam a usá-lo. Além disso, alguns algoritmos SHA também não são seguros. O código de criptografia real pode ter sido removido completamente do software.

--- Resposta errada anterior ---

Sua versão do Windows OpenSSL não possui os certificados raiz confiáveis que são usados para verificar o certificado TLS do servidor remoto.

Esta é a linha do Windows CURL onde é carregado os certificados de verificação:

* successfully set certificate verify locations:
*   CAfile: D:\dev\curl\bin\curl-ca-bundle.crt

E entrada semelhante no Linux:

* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 594 certificates in /etc/ssl/certs

Isso acontece porque o Windows OpenSSL não suporta o armazenamento de certificados do Windows, você precisa instalar manualmente os certificados por lá.

link tem algumas informações sobre o problema e como resolvê-lo.