Questão s_client não está falhando no certifcado revogado?


Estou executando o Firefox com o EFF HTTPS em todo lugar. Recentemente visitei o site do Lavabit para ver se aceitam doações:

enter image description here

A revogação é esperada considerando a história ....

No entanto, eu não estou duplicando o resultado usando o OpenSSL s_client. Abaixo, estou ficando Verify return code: 3 (unable to get certificate CRL) qual é X509_V_ERR_UNABLE_TO_GET_CRL, ao invés de X509_V_ERR_CERT_REVOKED: certificate revoked. O comando é:

openssl s_client -connect lavabit.com:443 -crl_check -CAfile valicert_class2_root.crt

O arquivo CA pode ser encontrado em Cadeia de Certificados Legacy ValiCert.

$ echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect lavabit.com:443 -crl_check -CAfile valicert_class2_root.crt 
CONNECTED(00000003)
depth=0 O = *.lavabit.com, OU = Domain Control Validated, CN = *.lavabit.com
verify error:num=3:unable to get certificate CRL
verify return:1
depth=3 L = ValiCert Validation Network, O = "ValiCert, Inc.", OU = ValiCert Class 2 Policy Validation Authority, CN = http://www.valicert.com/, emailAddress = info@valicert.com
verify return:1
depth=2 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certificates.godaddy.com/repository, CN = Go Daddy Secure Certification Authority, serialNumber = 07969287
verify return:1
depth=0 O = *.lavabit.com, OU = Domain Control Validated, CN = *.lavabit.com
verify return:1
---
Certificate chain
 0 s:/O=*.lavabit.com/OU=Domain Control Validated/CN=*.lavabit.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
 2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
 3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFWTCCBEGgAwIBAgIHJ3H9XXOouzANBgkqhkiG9w0BAQUFADCByjELMAkGA1UE
BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY
BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMTMwMQYDVQQLEypodHRwOi8vY2VydGlm
aWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkxMDAuBgNVBAMTJ0dvIERhZGR5
IFNlY3VyZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTERMA8GA1UEBRMIMDc5Njky
ODcwHhcNMTIwMjE3MDQwNzQ2WhcNMTcwMjE3MDQwNzQ2WjBTMRYwFAYDVQQKDA0q
LmxhdmFiaXQuY29tMSEwHwYDVQQLDBhEb21haW4gQ29udHJvbCBWYWxpZGF0ZWQx
FjAUBgNVBAMMDSoubGF2YWJpdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDPMNYGqnkvQBSlaen/VYxIdA57nANIYAAY4Nkt148BDgHdcgNJjjH7
YI9EM0hPRXF8lvU9F+dA0ejaxYz0KQMxzXS+uvfv2nPS97+HI3qlD9Tr4MsJRS2c
5TzUNQ03CxC9QCpMywwQJ/9KBCALCAjzlNalWCf1U2Vb7Q9+YKUa9YlPnVpOudSH
Z6H7y3+hAydrP/Wq6H8KP29xlExj8KNzY3EqVRqJvLQ+oVre4bqPO4FdWsSOGVGr
oMEXBTZewkefAN8PBk3lJ4ka/SLgiQtxnw2aNkKM2zw/wzPZU2Ri+J7sdCBd2aKy
YnfTn59ZELu5Kv/JdzARCcYMJ1GSI95pAgMBAAGjggG4MIIBtDAPBgNVHRMBAf8E
BTADAQEAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8E
BAMCBaAwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nb2RhZGR5LmNvbS9n
ZHMxLTY0LmNybDBTBgNVHSAETDBKMEgGC2CGSAGG/W0BBxcBMDkwNwYIKwYBBQUH
AgEWK2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS8w
gYAGCCsGAQUFBwEBBHQwcjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZ29kYWRk
eS5jb20vMEoGCCsGAQUFBzAChj5odHRwOi8vY2VydGlmaWNhdGVzLmdvZGFkZHku
Y29tL3JlcG9zaXRvcnkvZ2RfaW50ZXJtZWRpYXRlLmNydDAfBgNVHSMEGDAWgBT9
rGEyk2xF1uLuhV+auud2mWjM5zAlBgNVHREEHjAcgg0qLmxhdmFiaXQuY29tggts
YXZhYml0LmNvbTAdBgNVHQ4EFgQU8/u0eeUoWQaMfxTlv9NohxLD0dMwDQYJKoZI
hvcNAQEFBQADggEBAAUIImu3UtjasUc9ACCaoobHUWxU3SS1KQfGvt77NKIjzAuR
65H3lR7wQcVi4Ke4C/OXgyq4md5Q9W7s3IlbW++MdtFhzM8WG6yuI66C3zHG+DP4
qov8X7ckqrRU50cE1CAh/HZHIvGRYqKVjdxI/8ReX6DS6C8NaDHXaLsO/aClKuxQ
3J5WsqipUKsbhoDj6Z18yRFmdCks2+ySNPEF6YIz5/hYyPipeyWUqY8FIFSqmm0E
NHhiBp2s/3gROk2bIg1qxlNFnSRTttLQg6wEX8CGQ9EsTcqNk3LsdknZXlTQ7JCN
hK7okkwwXgUdFUkWZQej9XhWFAqkbCvC9hVI1Aw=
-----END CERTIFICATE-----
subject=/O=*.lavabit.com/OU=Domain Control Validated/CN=*.lavabit.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
---
No client certificate CA names sent
---
SSL handshake has read 5357 bytes and written 715 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 67541EBB72FADE3B388F12AD47964AFE...
    Session-ID-ctx: 
    Master-Key: A070BD05576771DD47459ED6071807FC...
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1397614017
    Timeout   : 300 (sec)
Verify return code: 3 (unable to get certificate CRL)
---
DONE

O certificado do servidor parece apontar para uma CRL válida.

Alguma idéia do que eu posso estar fazendo errado?


4


origem


Esta segunda revogação é por causa do Heartbleed, embora eu juro que o suporte de certificação de substituição perfeito sigilo antecipado. Eu não confio em nada sobre o OpenSSL neste momento - Ramhound
O certificado não tem nada a ver com o PFS. O PFS está usando apenas uma troca de chaves DHE ou ECDHE em vez de RSA. E eu não confiaria em nenhuma das pilhas TLS (todas as principais tinham problemas sérios no passado) nem confiaria na arquitetura atual da PKI. - Steffen Ullrich


Respostas:


Um deles, se os problemas do openssl forem sua má documentação e uso arcano. Mesmo com opção -crl_check ele não fará nenhuma verificação do OCSP nem fará o download de CRLs, nem poderá usar algo como -CRLfile com s_client. O que você precisa fazer é ter as CRLs e a autoridade de certificação no mesmo arquivo (localizando-o observando o código-fonte, que é realmente legível).

Desde que parece que você tem a CA já no formato PEM em valicert_class2_root.crt você pode fazer o seguinte para adicionar as CRLs também:

  • obtenha as CRLs do URL http://crl.godaddy.com/gds1-64.crl dado no certificado usando wget ou similar
  • porque as CRLs que você tem estão no formato DER, você precisa convertê-las em PEM com openssl crl -in gds1-64.crl -inform der -out crl.pem
  • o acréscimo crl.pem para o seu arquivo CA

Se você repetir o mesmo s_client comando você recebe Verify return code: 23 (certificate revoked)


8



Eu não sabia -crl_check não buscou a CRL. - jww
Não está documentado que isso acontece - e não documentado que isso não acontece. Na verdade, não está documentado em tudo o que realmente faz :( - Steffen Ullrich
Você pode trabalhar um Relatório de erros do OpenSSL / RT para os problemas de documentação? Você pode fazer referência a essa pergunta, se quiser. - jww
@Jww: Eu acho que isso seria uma perda de tempo. Existe muita documentação errada ou faltando com o openssl e eu realmente não consigo ver que eles acham que essas coisas são importantes o suficiente para corrigir, - Steffen Ullrich
No passado, foi definitivamente uma perda de tempo (isso é falar por experiência). As coisas mudaram nos últimos dois anos e a documentação é uma das solicitações mais fáceis de fazer (isso também é por experiência). As mudanças vieram depois do Heartbleed, que foi o catalisador para o financiamento de primeira classe do projeto das corporações e da Linux Foundation. Você deveria considerar tentar outra vez. - jww


Steffan me bateu na resposta enquanto eu pesquisava.

Sua resposta funciona melhor para coisas rápidas. Se você quiser usar o CApath, você precisa ter certeza de que os nomes dos arquivos estão corretamente hash ($ HASH.r0), que é totalmente não documentado em openssl. Você deve certificar-se de anexar TODAS as CRLs ao arquivo se estiver usando esse método, não apenas a CRL do primeiro certificado.

Existem algumas ferramentas que podem buscar CRLs para preencher seu sistema: http://wiki.nikhef.nl/grid/FetchCRL3


2



Obrigado Robbat2. Eu nunca uso CAPath desde que eu geralmente evito o zoológico de CA. Obrigado pela ferramenta. - jww
Você pode trabalhar um Relatório de erros do OpenSSL / RT para os problemas de documentação? Você pode fazer referência a essa pergunta, se quiser. - jww
@jww eu consegui consertar alguns meses depois da minha postagem. Agora está no documentação para c_rehash - robbat2