Mozilla 도움말 검색

고객 지원 사기를 피하세요. 저희는 여러분께 절대로 전화를 걸거나 문자를 보내거나 개인 정보를 공유하도록 요청하지 않습니다. "악용 사례 신고"옵션을 사용하여 의심스러운 활동을 신고해 주세요.

Learn More

Firefox reports a secure connection without existing certificate

  • 28 답장
  • 1 이 문제를 만남
  • 23 보기
  • 최종 답변자: pmc1

more options

When i click on the lock icon in the address bar, nothing happens (I would expect to see the encryption and certificate, but no widget opens). When I right-click into the page and select "View Page Info", "Security", "View Certificate", no certificate exists. Only generic info is shown (Servers+Authorities). Also an error is reported in the system log, confirming that no certificate exists: JavaScript error: chrome://browser/content/browser-siteIdentity.js, line 642: TypeError: issuerCert is undefined

Questions:

  • Why does Firefox show the lock icon while no certificate exists?
  • How does Firefox establish a secure connection without having a certificate? (From my understanding a certificate is needed for TLS to work.)

Version used: Firefox 78.12.0esr ('Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0'), no add-ons or plugins.

선택된 해결법

Looks like some progress on the bug report. However, Firefox 94 release comes in November, so it's some time away.

문맥에 따라 이 답변을 읽어주세요 👍 0

모든 댓글 (8)

more options

That's very helpful.

I wonder whether this is a Let's Encrypt specific issue? Two threads mentioned either them or a "free" certificate:

도움이 되셨습니까?

more options

However, that still doesn't explain the odd inconsistency between requests where some work (logged out) and other do not (logged in).

도움이 되셨습니까?

more options

jscher2000 said

That's very helpful. I wonder whether this is a Let's Encrypt specific issue?

Let's put this differently:

  1. does any commercial CA provide certificates with the must-staple feature?
  2. would anybody who is willing to pay for a cert, and who therefore most likely expects some return-on-investment, be willing to activate a feature that is not mandatory, and that is known to cause problems in some circumstances?
Two threads mentioned either them or a "free" certificate:

The main difference here: these people actually see this error! Their TLS handshake does effectively fail, because must-staple is engaged and the stapling OCSP response is someway missing (for whatever reason), or Firefox is made believe it would be missing. And a competent guy from letsencrypt forum stated that it is difficult to get must-staple properly working because of flaws in nginx. No idea how the situation is with apache.

But our case here is stranger: the TLS handshake works, the webpage works flawlessly, and only deep in the guts of Firefox is a (second?) verification done, which fails, and that failure is reported to nowhere (and can only be found by spamming the codebase with fprintf), but manages to occasionally(!) disturb the internal certChain store and subsequently the UI.

I don't get the rationale of this: when stapling is required, then either the reponse is present and good, or the response is bad or missing, and then the connection must be aborted.

jscher2000 said

However, that still doesn't explain the odd inconsistency between requests where some work (logged out) and other do not (logged in).

I gave up wondering about such. Today I cannot reproduce it at all, except when in turn accessing two individual applications with different hostnames and different certs.

글쓴이 pmc1 수정일시

도움이 되셨습니까?

more options

The question now is: how do we get this thing fixed?

The current state of affairs is: people may connect to my application, then they may want to check the security, and then they may experience that the lock icon has gone dead.

People without detailed background knowledge - and even people with some technical knowledge - will then most likely think that my application has somehow hacked their browser.

So this is very very bad, and has some urgency.

I have prepared an issue statement for the issue. What is next? Do I need a sponsor, or what?

Issue statement:

When loading a page with many ressources, firefox opens additional connections to the server, to fetch files in parallel. These connections do carry the 0x5 TLS extension (OCSP stapling), and they do invoke TLS verification. When verification fails, however, these connections are not necessarily abandoned. When must_staple is set in the certificate, that TLS verification will also invoke TLSFeaturesSatisfiedInternal(). For TLSv1.2 this works. With TLSv1.3 this results in error ERROR_REQUIRED_TLS_FEATURE_MISSING because the OCSPStapling response appears not to be available. A perceivable difference is that with TLSv1.3 these additional connections are opened with TLS extension 0x29 (pre_shared_key), which is not the case with TLSv1.2. The consequence of the failing verification is not an abandonment of the connection, neither is it reported to anywhere. Nevertheless, the consequence is that Firefox does not copy the certificate data to the presentation layer. At a subsequent change of the security context, e.g. when a new cookie is received, in the case when the TCP connections did stay open (a new TLS negotiation did NOT happen), this certificate data (that was NOT copied and therefore is undefined) is relied on from UI code. At that point it may appear that the lock icon is rendered nonfunctional, and no certificate data at all is shown.

도움이 되셨습니까?

more options

You can file a bug report on https://bugzilla.mozilla.org/

There might be a mailing list (now a Google Group) that others read more regularly, but I'm not sure which one is the most relevant:

https://lists.mozilla.org/

도움이 되셨습니까?

more options

jscher2000 said

You can file a bug report on https://bugzilla.mozilla.org/

Done. #1732476

What are the chances anyone will read it? (With other products, bug reports -even those with ready-made fixes attached- stay unread for ten or twenty years.)

도움이 되셨습니까?

more options

선택된 해결법

Looks like some progress on the bug report. However, Firefox 94 release comes in November, so it's some time away.

도움이 되셨습니까?

more options

Yeah, I admit I was wrong in not hoping on much progress.

November is no problem at all - I am rather used to OS release cycles where it can take a year or more to the next major version. The important thing is, it goes away from my stack, it is no longer me who must carry it along.

So, thanks a lot for Your help!

도움이 되셨습니까?

  1. 1
  2. 2
질문하기

글에 답글을 달기 위해서는 계정으로 로그인해야만 합니다. 계정이 아직 없다면 새로운 질문을 올려주십시오.