Por que o git parou de funcionar depois que o servidor desabilitou o SSLv3?

Question

Como a maioria dos outros, nosso servidor de repositório precisa desabilitar o SSLv3 (e v2) o mais rápido possível.

No entanto, isso parece quebrar nossos git-clients - pelo menos, no RHEL5 (conexões do meu desktop do FreeBSD funcionam bem). Mesmo o mais recente git (2.1.2) falha, e atualizar as bibliotecas OpenSSL para o mais recente do fornecedor não ajudou.

No entanto ! O mesmo git-client funciona muito bem contra o github.com - e o github.com já tem o SSLv3 desativado também. Por tentativa e erro, eu configuro a configuração SSL do nosso servidor (Apache) para que corresponda à do github:

SSLProtocol     ALL -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite  "AES128-SHA AES256-SHA RC4-SHA"

Ao executar sslscan no nosso servidor e no github, recebo a lista idêntica de cifras aceitas e rejeitadas. Mas git continua a falhar:

    % git clone https://git.example.net/git/puppet-hiera
    Cloning into 'puppet-hiera'...
    * Couldn't find host git.example.net in the .netrc file, using defaults
    * About to connect() to git.example.net port 443
    *   Trying 10.89.8.27... * connected
    * Connected to git.example.net (10.89.8.27) port 443
    * successfully set certificate verify locations:
    *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
      CApath: none
    * Unknown SSL protocol error in connection to git.example.net:443
    * Closing connection #0
    fatal: unable to access 'https://git.example.net/git/puppet-hiera/': Unknown SSL protocol error in connection to git.example.net:443

Agora, a única diferença perceptível que permanece entre o SSL do nosso servidor e o GitHub é que sslscan é capaz de produzir detalhes do certificado do GitHub, mas não consegue obtê-los do nosso servidor.

Quando eu me conecto ao nosso git-server da minha área de trabalho do FreeBSD, o mesmo comando git clone funciona. Em vez de falhar, depois de produzir CApath: none , vejo:

      CApath: none
    * SSL connection using AES128-SHA
    * Server certificate:
             subject: C=US; postalCode= ............

e a clonagem é bem-sucedida. Como faço para configurar o nosso servidor para que o git trabalhe com ele mesmo dos antigos sistemas RHEL5 - como acontece com os servidores GitHub?

Atualizar : tentando acessar nosso servidor com apenas curl , recebi um erro semelhante sobre a compatibilidade com SSL. No entanto, consegui superá-lo invocando curl com uma opção --tlsv1 explícita (também conhecida como -1 ). Então, o software nos sistemas RHEL5 é capaz dos protocolos e cifras necessários - como faço para usá-los por padrão ao invés de tentar os antigos e falhar?

    

Answer 1

Ok, aqui está o acordo. Desativar o SSLv3 no Apache de hoje significa que o servidor nem diria ao cliente que deseja usar o TLS. Se o cliente não iniciar a conversa com o TLS, o cliente falhará, mesmo que o possa falar com o TLS. Muito obrigado ao usuário Chris S. , que analisou o problema e até ofereceu um patch para o mod_ssl do Apache em responder a questão relacionada .

Tendo olhado para o patch de Chris, os desenvolvedores do Apache criaram um mais abrangente, que pode até se tornar parte do próximo lançamento do Apache. Ele apresenta uma nova opção para a diretiva SSLProtocols do Apache: ANY . Quando o Apache encontrar o ANY , ele informará ao cliente de conexão (via SSLv2Hello), que ele deve alternar para o TLS:

SSLProtocol ANY -SSLv2 -SSLv3

Estou colando o patch aqui para aqueles que não podem esperar pelo Apache 2.4.11.

Index: modules/ssl/ssl_private.h
===================================================================
--- modules/ssl/ssl_private.h    (revision 1635012)
+++ modules/ssl/ssl_private.h    (working copy)
@@ -295,8 +295,10 @@ typedef int ssl_opt_t;
 #define SSL_PROTOCOL_TLSV1_2 (1<<4)
 #define SSL_PROTOCOL_ALL   (SSL_PROTOCOL_SSLV3|SSL_PROTOCOL_TLSV1| \
                 SSL_PROTOCOL_TLSV1_1|SSL_PROTOCOL_TLSV1_2)
+#define SSL_PROTOCOL_ANY   (1<<5)
 #else
 #define SSL_PROTOCOL_ALL   (SSL_PROTOCOL_SSLV3|SSL_PROTOCOL_TLSV1)
+#define SSL_PROTOCOL_ANY   (1<<3)
 #endif
 typedef int ssl_proto_t;

Index: modules/ssl/ssl_engine_init.c
===================================================================
--- modules/ssl/ssl_engine_init.c    (revision 1635012)
+++ modules/ssl/ssl_engine_init.c    (working copy)
@@ -490,6 +490,7 @@ static apr_status_t ssl_init_ctx_protocol(server_r
     }

     cp = apr_pstrcat(p,
+                     (protocol & SSL_PROTOCOL_ANY ? "SSLv23, " : ""),
              (protocol & SSL_PROTOCOL_SSLV3 ? "SSLv3, " : ""),
              (protocol & SSL_PROTOCOL_TLSV1 ? "TLSv1, " : ""),
 #ifdef HAVE_TLSV1_X
Index: modules/ssl/ssl_engine_config.c
===================================================================
--- modules/ssl/ssl_engine_config.c    (revision 1635012)
+++ modules/ssl/ssl_engine_config.c    (working copy)
@@ -1311,6 +1311,9 @@ static const char *ssl_cmd_protocol_parse(cmd_parm
     else if (strcEQ(w, "all")) {
         thisopt = SSL_PROTOCOL_ALL;
     }
+        else if (strcEQ(w, "any")) {
+            thisopt = SSL_PROTOCOL_ANY|SSL_PROTOCOL_ALL;
+        }
     else {
         return apr_pstrcat(parms->temp_pool,
                parms->cmd->name,
Index: modules/ssl/ssl_engine_io.c
===================================================================
--- modules/ssl/ssl_engine_io.c    (revision 1635012)
+++ modules/ssl/ssl_engine_io.c    (working copy)
@@ -1137,6 +1137,7 @@ static apr_status_t ssl_io_filter_handshake(ssl_fi
      * IPv4 and IPv6 addresses are not permitted".)
      */
     if (hostname_note &&
+            !(sc->proxy->protocol & SSL_PROTOCOL_ANY) &&
         sc->proxy->protocol != SSL_PROTOCOL_SSLV3 &&
         apr_ipsubnet_create(&ip, hostname_note, NULL,
                 c->pool) != APR_SUCCESS) {

    

Answer 2

Gosto da explicação que você forneceu sobre como fazer ajustes no servidor para que os clientes git funcionem. Meu problema estava tentando se conectar ao jazzhub, onde eu não tenho a capacidade de mudar o servidor. Eu encontrei essa solução hoje (e ontem à noite):

link

Se você tiver algum feedback sobre isso, adoraria ouvi-lo.

-Michael