Não confiando em uma CA intermediária no Linux?


18

Deste blog .

CAs intermediárias são certificados assinados por uma CA raiz que podem assinar certificados arbitrários para qualquer site.

Eles são tão poderosos quanto as CAs raiz, mas não há uma lista completa daquelas em que seu sistema confia, porque as CAs raiz podem criar novas à vontade e seu sistema confiará nelas à primeira vista. Existem milhares de pessoas logadas no CT.

Este mês, surgiu um interessante, gerado aparentemente em setembro de 2015: "CA Intermediária de Serviços Públicos da Blue Coat", assinado pela Symantec. (Nenhum certificado assinado por esta CA alcançou os logs do CT ou o Censys até o momento.)

Eu pensei que seria uma boa ocasião para escrever como não confiar explicitamente em uma autoridade de certificação intermediária que seria confiável no OS X. Isso não impedirá que a autoridade de certificação raiz entregue um novo intermediário à mesma organização, mas melhor do que nada.

Quando tentei as etapas do blog no Ubuntu, baixei este certificado https://crt.sh/?id=19538258 . Quando abro o .crt, ele é importado para o Gnome Keyring, mas não consegui encontrar uma maneira de "não confiar" no certificado depois de importá-lo.

Respostas:


8

Para dificultar as coisas, o Linux tem mais de uma biblioteca para trabalhar com certificados.

Se você estiver usando o NSS da Mozilla, poderá desconfiar ativamente (sua terminologia) de um certificado usando a opção da certutil-t trustargs :

$ certutil -d <path to directory containing database> -M -t p -n "Blue Coat Public Services Intermediate CA"

Para o Firefox, <path to directory containing database>geralmente é ~/.mozilla/firefox/<???>.profileonde <???>estão alguns caracteres de aparência aleatória. (certutil é, por exemplo, no pacote libnss3-tools do ubuntu)

A repartição é a seguinte:

-M modificar o banco de dados

-t p para definir a confiança como Proibido

-n para executar a operação no certificado nomeado

Mesmo no NSS, nem todos os aplicativos compartilham o mesmo banco de dados; então você pode ter que repetir esse processo. Por exemplo, para fazer o mesmo no Chrome, altere -d <path>para -d sql:.pki/nssdb/.

$ certutil -d sql:.pki/nssdb/ -M -t p -n "Blue Coat Public Services Intermediate CA"

No entanto, nem todos os aplicativos usam o NSS, portanto, essa não é uma solução completa. Por exemplo, não acredito que seja possível fazer isso com a biblioteca OpenSSL.

Como conseqüência, qualquer aplicativo que use o OpenSSL para fornecer sua construção de cadeia de certificados (TLS, IPSec etc.) confiaria em uma cadeia um certificado Blue Coat e não há nada que você possa fazer para remover a CA raiz que a assinou. seu armazenamento de âncora confiável (que seria tolo, considerando que é uma CA raiz da Symantec, pois você desconfia de metade da Internet), enquanto os aplicativos que dependem do NSS podem ser configurados de forma mais granular para desconfiar de qualquer cadeia que possua o certificado Blue Coat. .

Por exemplo, acredito que o OpenVPN usa o OpenSSL como sua biblioteca de certificados; portanto, o big brother pode estar ouvindo o tráfego do OpenVPN sem o seu conhecimento, se você estiver se conectando a um provedor VPN comercial que usa o OpenVPN. Se você está realmente preocupado com isso, verifique quem é a CA raiz do seu provedor de VPN comercial - se for Symantec / Verisign, talvez seja hora de abandoná-los para outra pessoa?

Observe que o SSH não usa certificados X509, portanto, você pode conectar-se e fazer o túnel usando o SSH sem se preocupar com ataques MITM do Blue Coat.


Atualizei a pergunta para indicar que, quando clicava duas vezes no certificado, ele era importado para o chaveiro do gnome. Eu consegui encontrar uma maneira de importá-lo para o Firefox na minha resposta abaixo.
Raphael

Para o OpenSSL, remover o certificado não seria o mesmo que não confiar nele? Afinal, ele só pode validar certs que conhece.
Bratchley 27/05

11
@Bratchley - E se o certificado suspeito foi enviado (como deveria ser) como parte do handshake do TLS? Seria simplesmente confiável, a menos que exista uma maneira (como existe no Mozilla NSS, Windows e OS-X) de insistir que é sempre não confiável.
GarethTheRed

@garethTheRed Talvez esteja faltando alguma coisa, mas se a biblioteca exigir que o certificado seja validado, a execução de uma CRL ou a remoção da CA raiz confiável não resolverão o problema? Seja cliente ou servidor, ainda deve exigir validação.
Bratchley 31/05

11
Sim. O Bluecoat recebeu um certificado CA da Verisign para uso em dispositivos man-in-the-middle. O OP pergunta como desconfiar deste certificado. Portanto, trata-se de desconfiar de um certificado subordinado de que a CA de emissão superior (raiz neste caso) não será revogada quando, como você diz, não desejar desconfiar da raiz (Verisign).
garethTheRed

0

Ainda não posso comentar, então terei que comentar aqui que, no Ubuntu Gnome 15.10, quando uso a abordagem do @ garethTheRed, recebo:

~$ certutil -d ~/.mozilla/firefox/<directory>.default -M -t p -n "Blue Coat Public Services Intermediate CA" 
certutil: could not find certificate named "Blue Coat Public Services Intermediate CA": SEC_ERROR_BAD_DATABASE: security library: bad database.

~$ certutil -d sql:.pki/nssdb/ -M -t p -n "Blue Coat Public Services Intermediate CA"
certutil: could not find certificate named "Blue Coat Public Services Intermediate CA": SEC_ERROR_UNRECOGNIZED_OID: Unrecognized Object Identifier.

"Blue Coat Systems, Inc." também não funciona.

(Este é o certificado que eu importei: https://crt.sh/?id=19538258 )


Você baixou e importou o certificado primeiro?
Raphael

Sim, importei este: crt.sh/?id=19538258 . (Parece que posso comentar agora! :)
Diagon 27/05

Eu acho que você só pode comentar sua própria resposta. Ainda não tentei o procedimento.
Raphael

veja minha resposta abaixo
raphael

@raphael - Tentei editar abaixo, informando que: Embora o link acima descreva "-t p" como "proibido (explicitamente desconfiado)", a página de manual do Ubuntu 15.10 descreve como "p - Valid peer". Espero que você não tenha feito a coisa errada.
Diagon 27/05
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.