View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000722 | XMB1 | Research Tasks | public | 2024-12-01 07:09 | 2026-06-10 17:44 |
| Reporter | miqrogroove | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | acknowledged | Resolution | open | ||
| Target Version | 1.12.00 | ||||
| Summary | 0000722: How to Mitigate TLS Inspection | ||||
| Description | TLS Inspection is a potential threat to all web servers and to any client not administered by the end user. For example, the user of a computer at work or at a library might not realize the client's root trust list has been compromised. The result of a TLS Inspection deployment is that the TLS channel cannot be trusted at either end, and is effectively not confidential. This exposes passwords, session cookies, and all other data on the wire. Unfortunately, this is almost entirely beyond the control of the end user, and next to impossible to detect at the server. At the scripting level, almost nothing can be done short of redundantly implementing full asymmetric cryptography for both the client and server. If the inspection threat is sufficiently malicious, then scripting solutions are moot because script itself can be compromised to defeat any form of trust. At the transport level, the obvious remedy is something like Apache's `SSLVerifyClient require` directive. But this means a full PKI deployment to end users, just to protect confidentiality at the server level. It also implies end users would be tied to their own devices or risk trying to use personal certificates on foreign clients. To further complicate matters, the certificates would have to be tied to each user's account so that one user couldn't proxy traffic for another. This is a systemic risk to the whole Internet, but I am interested in any practical mitigation. | ||||
| Tags | No tags attached. | ||||
| MySQL Version | |||||
| PHP Version | |||||
| Web Server | |||||
| Browser | |||||
| Flags | |||||
| Original Reporter | |||||
| SVN Revision | |||||
| Git Commit | |||||
|
|
Bounced some ideas off of ChatGPT this morning. The conclusion was browsers are designed to enable this problem, and the only comprehensive solution is to not allow browsers. |
|
|
The mTLS solution is messy because it requires two separate domains for public and private browsing. Certificate delivery must be out of channel, either on the public website or via email for example. I'm leaning toward closing this issue but find it interesting that we might have a use case for mTLS. |
|
|
TODO: Ensure the Session system is sufficiently abstracted to allow for certificate auth implementations. Determine if any implementation should be baked in or left in the realm of hacks or future plugins. |
|
|
The Session system needs a Registry of Mechanisms and practical testing. Assigning to next major version. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-12-01 07:09 | miqrogroove | New Issue | |
| 2024-12-01 07:24 | miqrogroove | Description Updated | |
| 2024-12-01 07:25 | miqrogroove | Description Updated | |
| 2026-05-31 08:27 | miqrogroove | Description Updated | |
| 2026-05-31 08:27 | miqrogroove | Note Added: 0000619 | |
| 2026-06-06 22:10 | miqrogroove | Note Added: 0000620 | |
| 2026-06-07 08:52 | miqrogroove | Note Added: 0000621 | |
| 2026-06-07 08:53 | miqrogroove | Note Edited: 0000621 | |
| 2026-06-07 09:16 | miqrogroove | Status | new => acknowledged |
| 2026-06-10 17:44 | miqrogroove | Target Version | => 1.12.00 |
| 2026-06-10 17:44 | miqrogroove | Note Added: 0000622 |
