730734 - SSL + IPv6 without domain = sec_error_bad_database

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect)

Description

[Daniel Marschall]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Build ID: 20120215223356

Steps to reproduce:

Accessing https://[2001:1af8:4100:a061:0001:0000:0000:1337]/


Actual results:

sec_error_bad_database


Expected results:

The SSL connection should technically work, since it is the same as if I would enter https://ipv6.viathinksoft.de/ .

Comment 1

[Thomas Ahlblom]

2001:1af8:4100:a061:0001:0000:0000:1337 doesn't have a working rDNS and furthermore ipv6.viathinksoft.de uses an invalid security certificate.

But trying with https://[2001:1af8:4100:a061:0001:0000:0000:1337]/ instead of https://www.v6.facebook.com/ also creates the sec_error_bad_database error message.

Comment 2

[Daniel Marschall]

Hello.

It does not matter if this site has a valid security certificate or not. The bug here is that https://ipv6.viathinksoft.de/ TECHNICALLY works (even if the IP is not in the X.509 DNS-Name attribute) while https://[2001:1af8:4100:a061:0001:0000:0000:1337]/ does technically NOT work at all.

This IPv6 HAS a rDNS (it is very new, maybe your DNS-cache was not updated. Here is the result of the rDNS: http://whois.viathinksoft.de/reversedns/2001:1AF8:4100:A061:0001::1337). But why does rDNS matter? "sec_error_bad_database" should not appear, with or without rDNS. You don't need rDNS to let a HTTPS connection work, do you? (Note that not every Provider currently is rDNS capable with IPv6 addresses) So, the error message appears with and without rDNS entry.

I can confirm that https://[2620:0:1cfe:face:b00c::3] instead of https://www.v6.facebook.com shows sec_error_bad_database . (Additionally, the request takes long. Maybe a OCSP request over IPv4 fails?)

Comment 3

[Daniel Marschall]

Some more information

- If I disable OCSP in Firefox, the error still is there.

- I ran Wireshark on both IPs that raise the error. The result is always the same:

1. Client Hello
2. Server Hello
3. Certificate, Server Hello Done
4. Alert (Level: Fatal, Description: Bad Certificate)

this looks OK for me (Bad certificate probably because FB only has CN=*.v6.facebook.com). The failure is probably at certificate processing and not visible when watching the network traffic.

Comment 4

[Kai Engert [:KaiE:]]

Might also be a problem at the NSPR or NSS level?

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

In AuthCertificate in SSLServerCertVerification.cpp:

>  SECStatus rv = PSM_SSL_PKIX_AuthCertificate(cert, socketInfo,
>                                              socketInfo->GetHostName());

Here, PR_GetError() would correctly return SSL_ERROR_BAD_CERT_DOMAIN, because PSM_SSL_PKIX_AuthCertificate correctly returns SSL_ERROR_BAD_CERT_DOMAIN.

>  nsRefPtr<nsSSLStatus> status = socketInfo->SSLStatus();
>  nsRefPtr<nsNSSCertificate> nsc;
>
>  if (!status || !status->mServerCert) {
>    nsc = nsNSSCertificate::Create(cert);
>  }
>
>  CERTCertList *certList = nsnull;
>  certList = CERT_GetCertChainFromCert(cert, PR_Now(), certUsageSSLCA);
>  if (!certList) {
>    rv = SECFailure;
>  } else {
>    PRErrorCode blacklistErrorCode;
>    if (rv == SECSuccess) { // PSM_SSL_PKIX_AuthCertificate said "valid cert"
>      blacklistErrorCode = PSM_SSL_BlacklistDigiNotar(cert, certList);
>    } else { // PSM_SSL_PKIX_AuthCertificate said "invalid cert"
>      PRErrorCode savedErrorCode = PORT_GetError();

But, here, PORT_GetError()/PR_GetError() returns SEC_ERROR_BAD_DATABASE.

Comment 6

[Wan-Teh Chang]

We need to call
  PRErrorCode savedErrorCode = PORT_GetError();
immediately after the PSM_SSL_PKIX_AuthCertificate call.
(It's only necessary if PSM_SSL_PKIX_AuthCertificate doesn't
return SECSuccess.)  Otherwise the CERT_GetCertChainFromCert
call (even on success) may overwrite the current error code.

Comment 8

[Wouter DW]

Side note:
I found out that when you have a chained certificate that contains both the info on the IPv4 and the IPv6 address you can install the root certificate while connected using IPv4. Once this is done the IPv6 url works.

Comment 10

[[e-mail]]

is there any time schedule to fix this bug? thanks.

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

https://tbpl.mozilla.org/?tree=Try&rev=db7d7daa1f7c

Comment 12

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

https://tbpl.mozilla.org/?tree=Try&rev=0f8512cdf9a7

Comment 13

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: Call PORT_GetError at the correct time, to make sure we are getting the right error message

Comment 14

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: [NOT FOR CHECKIN] diff -w version of the patch above

Comment 15

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Here is the try run with this patch:
https://tbpl.mozilla.org/?tree=Try&rev=0f8512cdf9a7

Comment 16

[[e-mail]]

great, thanks, Brian.

Comment 17

[Wan-Teh Chang]

Comment on attachment 623228 [details] [diff] [review]
[NOT FOR CHECKIN] diff -w version of the patch above

Your patch looks correct to me.  I have a question.

>   SECStatus rv = PSM_SSL_PKIX_AuthCertificate(cert, infoObject,
>                                               infoObject->GetHostName());
>+  PRErrorCode error = (rv == SECSuccess) ? 0 : PORT_GetError();

...

>   CERTCertList *certList = nsnull;
>   certList = CERT_GetCertChainFromCert(cert, PR_Now(), certUsageSSLCA);
>   if (!certList) {
>+    if (error == 0) {
>+      error = PORT_GetError();
>+    }

Why do you prefer the error code of PSM_SSL_PKIX_AuthCertificate over
the error code of CERT_GetCertChainFromCert?

Comment 18

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Wan-Teh Chang from comment #17)
> Why do you prefer the error code of PSM_SSL_PKIX_AuthCertificate over
> the error code of CERT_GetCertChainFromCert?

This is why originally I marked this as depending on bug 733454, so that I wouldn't have to choose which one to use.

My thinking is that we want to prefer the error from libpkix to the error from CERT_GetCertChainFromCert, when libpkix is enabled, and that the call to CERT_GetCertChainFromCert is part of a hack that will eventually go away (in bug 733454).

Otherwise, I am not sure it is significantly better one way or another. Do you have an opinion?

Comment 19

[Kai Engert [:KaiE:]]

Brian, shouldn't you provide an automated test?

Comment 20

[Kai Engert [:KaiE:]]

Comment on attachment 623228 [details] [diff] [review]
[NOT FOR CHECKIN] diff -w version of the patch above

r- because missing tests

Comment 21

[Stefan Winter]

This is still an issue on Firefox 17 (openSUSE 12.2 build). 

It looks like it is reproducible on every single IPv6 HTTPS website I found. E.g.

https://www.restena.lu works fine, but
https://[2001:a18:1::83]/ does not and throws this sec_error_bad_database error.

Even if there are no automated tests: this issue is *so* easy to reproduce, testing the patch should be /really/ easy in an interactive way. Basically, just click the link above.

Comment 22

[Stefan Winter]

FWIW, this seems to have been fixed somewhere along the way. Accessing IPv6 sites by their address, such as in the test case above, now works. (For the test case, you still get a "This connection is untrusted", but that's unrelated to the "bad_database" error you got before.

So, FIXED, WORKSFORME. I'd be glad if someone else could confirm.

Comment 23

[Phil Pishioneri]

Using URLs in comment 21 (and my own website) I can confirm: no "bad database" error, just appropriate "This connection is Untrusted" panel due to mismatches.

Comment 24

[Dana Keeler (she/her) [:keeler]]

This would have been fixed by the switch to mozilla::pkix.