Open Bug 1939854 Opened 2 months ago Updated 22 days ago

foscos.fssai.gov.in - "Secure connection failed" when accessing the page

Categories

(Web Compatibility :: Site Reports, defect, P2)

Desktop
Windows 10

Tracking

(Webcompat Priority:P1, firefox133 affected, firefox134 affected, firefox135 affected)

Webcompat Priority P1
Tracking Status
firefox133 --- affected
firefox134 --- affected
firefox135 --- affected

People

(Reporter: rbucata, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: webcompat:blocked, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs])

User Story

platform:windows,mac,linux,android
impact:site-broken
configuration:general
affects:all
branch:release
diagnosis-team:security

Attachments

(1 file)

Environment:
Operating system: Windows 10
Firefox version: Firefox 133.0

Steps to reproduce:

  1. Navigate to: https://foscos.fssai.gov.in/public/fbo/eligibility/M/LIC
  2. Observe

An error occurred during a connection to foscos.fssai.gov.in. Peer’s Certificate has been revoked.

Error code: SEC_ERROR_REVOKED_CERTIFICATE

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

Expected Behavior:
The page loads

Actual Behavior:
"Secure connection failed" error message

Notes:

  • Reproduces regardless of the status of ETP
  • Reproduces in firefox-nightly, and firefox-release
  • Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/145596

Attached image ssl lab report.png

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

They're clearly serving a revoked certificate, but Chrome doesn't care. I guess this is crlite-related, but I don't know enough about this, so I'll leave this to be diagnosed by the security team.

Severity: -- → S2
User Story: (updated)
Priority: -- → P2

That certificate is indeed revoked. Best case scenario is we reach out to them and have them get a certificate that isn't revoked. Worst case is we don't get a response and it'll stay broken until we ship CRLite in "important revocation reasons only" mode, whereupon Firefox will no longer consider that certificate revoked (because it doesn't have a revocation reason).

Depends on: 1548030

Correction - I've been told that when we ship CRLite, it will cover all revocations, so this certificate will still show up as revoked in Firefox. If the operators of that site want it to work in Firefox, they need to use a certificate that isn't revoked.

No longer depends on: 1548030

Why isn't Chrome bothered by the fact that the certificate is revoked?

Flags: needinfo?(dkeeler)

Chrome has a curated set of revocations that it thinks are important (we believe it's basically the set of revocations where CAs have specified the revocation is due to key compromise). For all other revocations, Chrome doesn't care, and lets users connect anyway.

Flags: needinfo?(dkeeler)

Would it be practical for us to use the same set of revocations as Chrome?

Flags: needinfo?(dkeeler)

We could, but my understanding is our position is that there are revocations that aren't due to key compromise that are important, and by enforcing those, we protect our users. When we ship CRLite, which will provide performant, private revocation information, Firefox will be more secure than Chrome in that respect.

Flags: needinfo?(dkeeler)
Webcompat Priority: --- → P1
No longer blocks: 1943347
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: