Path: mv.asterisco.pt!mvalente
From: mvale…@ruido-visual.pt (Mario Valente)
Newsgroups: mv
Subject: Firefox Bounty Followup
Date: Sun, 01 Jul 07 22:16:21 GMT
Obrigado pelos varios comentarios *construtivos* recebidos.
Ate agora ainda nenhuma sugestao resolveu o “problema”, embora
haja alguns contributos interessantes. Para beneficio de todos
aqui fica o comentario aos excertos mais importantes.
”
Eu experimentei quer com o FF2 e como Safari 3 Beta, e os resultados que obtive foram rigorosamente os mesmos. Isto e, a CA de raiz nao e reconhecida pelo browser, o que ate faz sentido pois a mesma nao se encontra na lista de CAs raiz na qual o browser confia.
”
Mas esta e a questao. O Firefox para na CA da ECEE (CA do Estado
Portugues), quando na realidade esse certificado indica por sua
vez uma CA hierarquicamente superior (a da GTE Cybertrust, essa sim
ja reconhecida na lista de CAs do Firefox). O IE nao fica por ai e
segue essa indicacao adequadamente e apresenta toda a hierarquia,
pelo que nao aparece qualquer mensagem de “certificado nao conhecido”.
“Isto tem um cheiro *MUITO*FORTE* a algo que a RedHat e a Mozilla Foundation sao obrigadas por lei a ter em conta, mas que o Ubuntu nao. talvez patentes, uma vez que restricoes a exportacao de tecnologia nao devem ser ou tambem nao viria no Internet Explorer (a menos que este seja quem tem o bug).
Nao me parece que seja um problema relacionado com UTF-8 vs quoted-printable como sugere o Mario, uma vez que nao vejo caracteres que justifiquem tal tipo de problemas.”
http://blog.softwarelivre.sapo.pt/2007/07/02/recompensa-do-itij-de-1000e-para-bug-no-firefox/
Isto podia ser uma hipotese. Nao fosse o facto de, conforme
eu referi no post inicial, o problema acontecer mesmo quando
a cadeia de certificados e colocada directamente no browser
(vide mais abaixo).
”
Then, the problem, as described in the bug page, isnt that “the standard isn’t clear”: if you actually read the RFC’s, you’ll see that the https server has the obligation to send a complete certificate chain.
Now, IMHO the target should be “have the issue properly solved”, so, since the issue is that, by RFC, the https server must do something that isn’t doing nowadays, then having a “bug bounty” over Firefox isn’t helping. If the target is to have Firefox with the same behaviour as the other browsers, then it would be nice to have a proper enhancement request submitted and aprooved, and only after that a “patch bounty” for an implementation of the solution. I could do some more work on this issue – heck, I could even go after that bounty. Presented the way it is, I’m just not interested: seems to me that the solution proposed is ignoring the fact that the target website is broken since it is not complying with the standards involved.
”
http://mindboosternoori.blogspot.com/2007/07/bug-245609-mozilla-not-getting.html
The target website is complying with the standards involved. It
uses a part of the standard that allows for the certificate chain
not to be all available at the target site but to be fetched as
needed.
The standard does say that this part MUST NOT be critical. But then,
by the same thinking, Firefox shouldnt come up with an error message
misleading the user into thinking that there’s something wrong with
the certificate.
Furthermore: even if you locally install the certificate chain, you
still get the same message. So there *IS* a problem with the certificate
validation procedure in Firefox. See the message and comments below.
You can also read the Firefox bug report originally mentioned, that
states that the certificate chain is indeed OK, there’s no reason for
Firefox not to to trust the site and that its probably *another*
problem. I stated precisely that in my initial post.
”
Lendo o historico do bug e as especificacoes entende-se realmente que isso *nao* e um bug do firefox, mas sim uma mal-configuracao dos servidores. No entanto, e razoavel que essa feature seja implentada, mas como eu disse no inicio, vai exigir uma segunda conexao TCP a ser realizada diretamente pelo modulo de SSL, que nao e uma situacao prevista no mozilla hoje (principalmente por precisar acessar as configuracoes de proxy do mozilla).
No entanto, o problema com o site especificado e outro. O servidor esta sim enviando o chain completo de certificados. Mas por algum motivo o firefox nao esta utilizando o certificado GTE Cybertrust Root que ja e instalado por padrao…
”
Precisamente. Independentemente do bug referido, o problema
nao e esse ou pelo menos nao e so esse. Mesmo instalando a
cadeia de certificados no browser o Firefox continua a nao
seguir adequadamente a hierarquia. Tendo em conta que a cadeia
e valida, que outros browsers a conseguem seguir e, eliminando
a solucao “o problema e do lado do servidor que devia ter a
cadeia toda” (bastando para tal instalar a cadeia localmente
no browser), o problema e outro. E a unica razao que ate agora
pudemos aventar e o problema dos encodings (vide abaixo)
”
O problema devera estar relacionado com a construcao da chain de trust
ate a Root CA.
O vosso certificado apenas publica na extensao AIA:
[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=https://ocsp.ecce.gov.pt
A publicacao da extensao 1.3.6.1.5.5.7.48.2 podera resolver o assunto.
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=pathtoCAcert
”
Este comentario ja mostra trabalho de casa :) Obrigado. De
facto o campo AIA tem uma referencia OCSP. E o Firefox tem
a opcao de seguir certificate chains usando o OCSP. Mas, mesmo
assim, nao funciona :-). Vide comentarios acima.
Mudar o AIA para referir a CA 48.2 era boa ideia, nao fosse
o facto de o Firefox nao seguir esse campo.
Para quem estiver interessado em dar ajuda adicional (ou
dar a resolucao para o problema), alguns dados adicionais
sobre o ponto onde estamos no momento:
”
Conforme o RFC 3280 –
