On 24.01.2011 15:10, Ben Bucksch wrote:
In my nsIBadCertListener2::notifyCertProblem(), I try to getInterface(nsITransportSecurityInfo) from socketInfo, because nsNSSIOLayer.cpp::nsNSSBadCerthandler() lines 3348 and 3577 suggest that it should be a nsNSSSocketInfo object, which implements nsITransportSecurityInfo. But the socketInfo.getInterface(Ci.nsITransportSecurityInfo) fails. I am puzzled why, maybe I misread the source.

Indeed, nsIBadCertListener2::notifyCertProblem()'s socketInfo is defined as nsIInterfaceRequestor, and this seems to get nsISSLSocketControl::notificationCallbacks, i.e. the callback that the *app* set. I don't know which purpose this serves, at least not a single JS implementor uses this, and it's not documented.

However, I can - independent of the IDL definition - indeed QI socketInfo directly to nsITransportSecurityInfo, and I get the same as with socket.securityInfo:

tried to access socket.securityInfo, QI that to nsITransportSecurityInfo, ... tsi.shortSecurityDescription and tsi.errorMessage are both null.

I want to (given/assuming that I can't tell NSS the correct hostname):

   * know when a cert error happens (DONE by implementing
     nsIBadCertHandler2)
   * get the hostname in the cert (DONE [1], and the expected hostname
     that I contacted (DONE of course)
   * check what the exact error is, and handle "hostname mismatches
     cert" error only (OPEN - that's why I tried to get the
     nsITransportSecurityInfo.errorMessage above, so I don't know how
     to achieve that)
   * override that error only if the hostname in the cert matches my
     expected hostname (OPEN: I can suppress the error dialog, but
     don't know how to let the connection proceed)


[1]
socketInfo.QueryInterface(Ci.nsISSLStatusProvider)
  .SSLStatus.QueryInterface(Ci.nsISSLStatus)
  .serverCert // nsIX509Cert.idl
  .commonName;
<http://mxr.mozilla.org/comm-central/source/mozilla/browser/app/profile/extensions/testpi...@labs.mozilla.com/modules/remote-experiment-loader.js#43>

  and while tsi.securityState is 4 (which is of course not defined in the IDL)

FWIW, <https://developer.mozilla.org/En/How_to_check_the_security_state_of_an_XMLHTTPRequest_over_SSL> suggests that this equals Ci.nsIWebProgressListener.STATE_IS_SECURE and friends.

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to