I did try your patch and it produced the base64 output as you
mentioned. But it was different from the format that you see in
cert_override.txt, where that magic string starts with a sequence of
"AAAA...". But interestingly enough, your string also worked. When I
injected the self-signed cert in to cert8.db& populated the
cert_override.txt with your magic string output from pp, firefox
accepted it! So now, this throws another wrench in my understanding of
how FF actually deals with cert_override. Does the exact format the
magic string actually matter? Or does firefox just check for the
certificate in its cert store (cert8.db)& verify cert fingerprint in
cert_override.txt and allow access to the site?
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsCertOverrideService.cpp#259
This is a bit of NSS that reads the cert_override.txt file in case you
want to investigate it more. If it has to do with the flurry of A's at
the beginning (present in one string and not the other), I think they
might just be leading zeroes or padding or something. Since A = 0 in
Base64, perhaps the binary data scheme allows these leading zeroes,
stripping them out during decoding. If that's the case, you could end
up with different-looking encoded strings with the same canonical
decoded value -- some with A's at the beginning, and some without.
I'm not an expert in this bit of code, however, so I'm just making a
half-educated guess here. However, I'm pretty sure the "magic string's"
contents (b64-encoded stuff) does indeed matter for cert override. It
is used by the code referenced above, and it seems to have a comparison
method here:
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsCertOverrideService.cpp#718
The actual format of the encoded string may not matter, so long as it
decodes to an equivalently valid key.
-Sid
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
