Bug 245609 – Mozilla not getting certificate issuer from Authority Information Access CA Issuers
Some people alerted me on a "bug bounty" for Firefox (even if the issue is with Mozilla Core and not on Firefox): the Portuguese Ministry of Justice will pay a 1000 Euro reward for those who fix this "bug". What's the catch?
Well, first of all, this is not a bug. It is correctly tagged as a RESOLVED as INVALID enhancement, and it is. It could be, if anyone cares to do so, a VALID enhancement, simply by changing the context: something like "there's nothing that can happen wrong if we emulate the behaviour of the other browsers, and it would be better for users", explained, would suffice.
Now, the problem is that the message that announces the bounty says:
Well, if you're trying to convince those who maintain a piece of software that they should implement an enhancement, you shouldn't start by calling the actual behaviour as "really stupid", specially when that behaviour is RFC compliant, thus not a bug. 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. Supporting a broken web by changing the behaviour of one web browser is plain blindness, specially because you can't garantee that (1) every browser acts the same way, and (2) in five years you have a major browser out there that implements everything well but still does not support broken cert chains.
Useful links:
http://www.ietf.org/rfc/rfc2246.txt;
http://www.ietf.org/rfc/rfc2459.txt;
http://www.ietf.org/rfc/rfc3280.txt;
http://www.ietf.org/rfc/rfc4346.txt;
http://tools.ietf.org/id/draft-ietf-tls-ssl-version3-00;
http://www.ietf.org/html.charters/tls-charter.html.
From RFC 4346:
Well, first of all, this is not a bug. It is correctly tagged as a RESOLVED as INVALID enhancement, and it is. It could be, if anyone cares to do so, a VALID enhancement, simply by changing the context: something like "there's nothing that can happen wrong if we emulate the behaviour of the other browsers, and it would be better for users", explained, would suffice.
Now, the problem is that the message that announces the bounty says:
But somehow that doesnt seem enough to justify the problem.
First because it seems really stupid for Firefox not to
implement something that all other browsers implement and just
saying "lets wait till the standard is clear".
Second because its not a solution if you just say "reconfigure
the server and make sure that the intermediate certificate is
served". The other browsers dont need that.
Third because even if you install the certificates locally
in your browser, the problem continues. It seems to be
related to a possible problem with comparisons of fields
encoded in UTF-8 in one certificate and encoded in quoted
printable in others.
Well, if you're trying to convince those who maintain a piece of software that they should implement an enhancement, you shouldn't start by calling the actual behaviour as "really stupid", specially when that behaviour is RFC compliant, thus not a bug. 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. Supporting a broken web by changing the behaviour of one web browser is plain blindness, specially because you can't garantee that (1) every browser acts the same way, and (2) in five years you have a major browser out there that implements everything well but still does not support broken cert chains.
Useful links:
http://www.ietf.org/rfc/rfc2246.txt;
http://www.ietf.org/rfc/rfc2459.txt;
http://www.ietf.org/rfc/rfc3280.txt;
http://www.ietf.org/rfc/rfc4346.txt;
http://tools.ietf.org/id/draft-ietf-tls-ssl-version3-00;
http://www.ietf.org/html.charters/tls-charter.html.
From RFC 4346:
certificate_list
This is a sequence (chain) of X.509v3 certificates. The sender's
certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority may optionally be omitted from the chain,
under the assumption that the remote end must already possess it
in order to validate it in any case.
No comments:
Post a Comment