search

AsamK / signal-cli

signal-cli provides an unofficial commandline, JSON-RPC and dbus interface for the Signal messenger.
GNU General Public License v3.0
3.13k stars 295 forks source link

Signal certificate not trusted behind proxy - MITM inspection edition #1565

Open numericOverflow opened 1 month ago

numericOverflow commented 1 month ago

I am running into this same issue as #299, but have some additional info referencing that issue.

Whenever I try to register behind a seamless MITM SSL inspection proxy, I (naturally) get an ssl handshake error:

Failed to register: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target (SSLHandshakeException)
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I know I am behind a corporate firewall/proxy that does MITM inspection. Obviously, this is known to cause SSL issues as in general, anything MITM is frowned upon from a privacy standpoint, but in this case its the "good guys"™ doing it. Is there a way to override the cert to allow the corp MITM to connections occur?

I would never want to do this in a private situation because it undermines the assumptions of privacy, but for a work scenario where the MITM is required and I'm OK with it for governance, can this be done?

I've tried a couple things so far: 1) Extracting the trusted CA's from a windows machine, then adding them to the JVM's CA keystore, but that didn't work. (JAVA_HOME\lib\security\cacerts).

I used certutil to extract the certs, and keystore tool import to the above cacerts store.

This should have the MITM CA, but can't see exactly which CA is used, so can't be sure, but seems not to help at all. Got same errors as above prior to modifying cacerts store.

2) Next I tried replacing the whisper.store with the cacerts I built out above (which should have MITM root certs) as suggested here when the certs got updated to backport to older versions, but I get a new error

2024-08-13T09:16:03.326-0500 [main] DEBUG org.asamk.signal.util.IOUtils - XDG_RUNTIME_DIR
not set, falling back to temp dir
2024-08-13T09:16:03.348-0500 [main] DEBUG org.asamk.signal.App - Starting signal-cli 0.13.5
2024-08-13T09:16:03.721-0500 [main] DEBUG org.asamk.signal.util.IOUtils - XDG_DATA_HOME not set, falling back to home dir
2024-08-13T09:16:04.119-0500 [main] INFO  com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Starting...
2024-08-13T09:16:04.296-0500 [main] INFO  com.zaxxer.hikari.pool.HikariPool - HikariPool-1 - Added connection org.sqlite.jdbc4.JDBC4Connection@50fe837a
2024-08-13T09:16:04.298-0500 [main] INFO  com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Start completed.
Error loading or creating state file: java.io.IOException: Wrong version of key store. (AssertionError)

I'm assuming this might be due to the fact that the cert is hardcoded somewhere to stop MITMs.

Thoughts?? I'm hitting my wall of knowledge/options without some suggestions.

Gunni commented 3 weeks ago

Just a random passer by here, I'd suggest your IT department replace MITM with endpoint security.

MITMing traffic like this is very frowned upon and you are basically on your own with issues.

numericOverflow commented 3 weeks ago

Just a random passer by here, I'd suggest your IT department replace MITM with endpoint security.

MITMing traffic like this is very frowned upon and you are basically on your own with issues.

I personally agree with you, but that decision is no where near my realm of influence. I might as well file a complaint with the Great Red Spot on Jupiter asking that it be a bit less windy.