💾 Archived View for gemi.dev › gemini-mailing-list › 000501.gmi captured on 2023-12-28 at 15:48:13. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
Hi, I wanted to set up my own Gemini server today. I think I got MITM-attacked by China. This highlights the question I wanted to ask for some time: can't TOFU be easily MITM-ed by state actors? Is it actually any better than CA certificates or does it only replace trust in CAs with trust in all ISPs and hardware in between the server and the client? How would TOFU work for someone out of a country that firewalls the internet and can replace all self-signed certificates for port 1965 on the fly? If TOFU fails in this scenario (which is common for hundreds of millions of people today) can we really say that Gemini protects privacy? Details: I am in Vilnius, Lithuania. My IP is in this range: ``` inetnum:??????? 78.59.128.0 - 78.59.255.255 netname:??????? Telia-Lietuva descr:????????? Telia Lietuva, AB country:??????? LT ``` I got a VPS with Debian 9 in the same city. It's current hostname is naujenai.lt and IP is in this range: ``` inetnum:??????? 94.176.232.0 - 94.176.239.255 netname:??????? LT-LITHUANIA-20080814 country:??????? LT ``` I downloaded, compiled and installed https://git.sr.ht/~sircmpwn/gmnisrv on the VPS. Commit: ``` gmnisrv$ git log commit cb2c84b0ad9aadd4c92d8ef978c2bfca578cd3c4 Author: Mark Dain <mark at markdain.net> Date:?? Sat Nov 21 13:56:37 2020 +0000 ``` I use a locally built https://github.com/skyjake/lagrange to browse gemini:// Commit: ``` commit ca89eeab5c89107f675bd4d8de97ede364d8d902 (HEAD -> release, tag: v0.10.0, origin/release) Merge: 6e1e7d0 b9f7a12 Author: Jaakko Ker?nen <jaakko.keranen at iki.fi> Date:?? Sat Nov 21 22:25:57 2020 +0200 ``` I opened my new server URL in Lagrange. Then tried a non-existing URL (I was trying to configure URL rewriting for gmnisrv). I got this in my gmnisrv console: ``` $ gmnisrv [gmnisrv] generating certificate for naujenai.lt [gmnisrv] generating certificate for localhost [gmnisrv] listening on [::]:1965 [gmnisrv] listening on 0.0.0.0:1965 [gmnisrv] gmnisrv started 36.130.78.59 naujenai.lt /? 57ms??? 39 20 text/gemini 154.170.78.59 naujenai.lt /test.gmi? 67ms???? 0 51 Not found ^C[gmnisrv] gmnisrv terminating ``` ``` $ gmnisrv [gmnisrv] loaded certificate for naujenai.lt [gmnisrv] loaded certificate for localhost [gmnisrv] listening on [::]:1965 [gmnisrv] listening on 0.0.0.0:1965 [gmnisrv] gmnisrv started 39.92.78.59 naujenai.lt /? 58ms??? 39 20 text/gemini 143.238.78.59 naujenai.lt /asdf.gmi? 66ms???? 0 51 Not found ``` Whois queries for the IPs in the gmnisrv log: ``` $ whois 36.130.78.59 ... inetnum:??????? 36.128.0.0 - 36.191.255.255 netname:??????? CMNET descr:????????? China Mobile Communications Corporation descr:????????? Mobile Communications Network Operator in China descr:????????? Internet Service Provider in China country:??????? CN ``` ``` $ whois 39.92.78.59 ... inetnum:??????? 39.64.0.0 - 39.95.255.255 netname:??????? UNICOM-SD descr:????????? China Unicom Shandong province network descr:????????? China Unicom country:??????? CN ``` ``` $ whois 143.238.78.59 ... NetRange:?????? 143.238.0.0 - 143.238.255.255 CIDR:?????????? 143.238.0.0/16 NetName:??????? APNIC-ERX-143-238-0-0 NetHandle:????? NET-143-238-0-0-1 Parent:???????? NET143 (NET-143-0-0-0-0) NetType:??????? Early Registrations, Transferred to APNIC OriginAS: Organization:?? Asia Pacific Network Information Centre (APNIC) ... Country:??????? AU ``` ``` $ whois 154.170.78.59 ... inetnum:??????? 154.160.0.0 - 154.175.255.255 netname:??????? GH-SPACEFON descr:????????? Scancom Ltd. country:??????? GH ``` Note that IP addresses change between requests from the same browser to the same server. I suspect my Huawei 4G router. I bought it locally a few years ago when very few options were available. I was planning to replace it for some time. -- Emilis Dambauskas gemini://tilde.team/~emilis/
On 2020-11-28 at 09:28 -05:00, Emilis <emilis at emilis.net> wrote: > can't TOFU be easily MITM-ed by state actors? > > Is it actually any better than CA certificates or does it only replace > trust in CAs with trust in all ISPs and hardware in between the server > and the client? TOFU could be MITM'd. It replaces the CA mechanism by the assumption that the first time you connect to a host, you get the right key/cert, and will ensure that any subsequent connection uses the same key pair. So if the first connection is MITM'd, your client will accept the phony cert but all subsequent connections will need to be MITM'd with the same phony cert in order to keep you client quiet. If the first connection is NOT MITM'd, then any subsequent MITM attempt would then raise alarm bells. > How would TOFU work for someone out of a country that firewalls the > internet and can replace all self-signed certificates for port 1965 on > the fly? > > If TOFU fails in this scenario (which is common for hundreds of millions > of people today) can we really say that Gemini protects privacy? You're right - it wouldn't protect the privacy of people under that scenario (assuming the state actor is sufficiently motivated to do this interception/replacement under TOFU constraints). I'm not sure what a good solution to this is. > Note that IP addresses change between requests from the same browser to > the same server. Those logs do look a little funky, but luckily we don't need to rely on IP addresses to check your hypothesis: all you need to do is match the fingerprint/hash of the cert being presented by Lagrange with the hash of the cert generated on your server. If they don't match, then you have definitively been MITM'd.
> Hi, Hello > I wanted to set up my own Gemini server today. I think I got MITM-attacked > by China. snip > I am in Vilnius, Lithuania. My IP is in this range: > inetnum:?????????????? 78.59.128.0 - 78.59.255.255 snip > 36.130.78.59 naujenai.lt /?? 57ms?????? 39 20 text/gemini > 154.170.78.59 naujenai.lt /test.gmi?? 67ms???????? 0 51 Not found So we can't blame the PRC on this. It is a bug in gmnisrv. I mailed Drew the following in September, but it seems my fix got ignored. I suppose it only affects certain architectures, and only ipv4. What is happening is that the address decoding routine input is shifted by 2bytes, hence your 78.59 appears in the wrong place, and the first two bytes are bogus. Your general point about TOFU/MITM still stands though. We can reduce the risk by not expiring keys, and by maybe showing fingerprints in the browser, in various caches and maybe even in the links occasionally. > I noticed on some platforms the logging logic for the > server (log.c:23) uses addr->sa_data which is not aligned, > as the short is only 2 bytes long, and the char[] happens > immediately after that: > > eg addr=0xb6e01014, fam=0xb6e01014, data=0xb6e01016 > > and so doesn't map directly on to the address structure. > I solved this with a horrible > > const char *addrs = inet_ntop(addr->sa_family, (void *)&(((struct sockaddr_in *)addr)->sin_addr), abuf, sizeof(abuf)); For completeness, the proper fix would involve doing a switch on sa_family, and grabbing the proper location on a per address family basis - things that a type safe language would have insisted on, but which C (a very sharp tool requires sharp users) allows us to bypass. regards marc PS: Comments from the peanut gallery advocating for a newer language are of course wrong. C is still the better choice ;-) I suspect Emilis test system doesn't have enough RAM to be even supported by some shinier runtimes, nevermind the CPU architecture... -- CC-SA
On 11/28/20 5:14 PM, Ben Burwell wrote: > Those logs do look a little funky, but luckily we don't need to rely on > IP addresses to check your hypothesis: all you need to do is match the > fingerprint/hash of the cert being presented by Lagrange with the hash > of the cert generated on your server. If they don't match, then you have > definitively been MITM'd. I can't match the server certificate to it's browser fingerprint. I am not sure I am using the correct methods. My Lagrange `.config/lagrange/trusted.txt` has this line: ``` naujenai.lt 1638096010 95c34bf23ad26f64627138875ce2b251048fcfea9be905a7c9915325fb0e3546 ``` I attached my `naujenai.lt.crt` which was generated by gmnisrv. I ran these commands on the certificate file: ``` $ openssl x509 -in naujenai.lt.crt -noout -fingerprint -sha256 SHA256 Fingerprint=83:D8:96:B8:83:2B:D7:04:A2:E1:36:78:15:4B:1D:4F:30:A1:13:22:79: 57:AD:68:A8:70:2B:49:9F:1D:D0:65 ``` ``` $ openssl x509 -in naujenai.lt.crt -outform DER -out naujenai.lt.der $ sha256sum naujenai.lt.der 83d896b8832bd704a2e13678154b1d4f30a113227957ad68a8702b499f1dd065 naujenai.lt.der ``` Lagrange seems to be using sha256 fingerprints, but I am not a C developer so I can't be sure: https://git.skyjake.fi/skyjake/the_Foundation/src/branch/master/src/tlsrequest.c#L310 -- Emilis Dambauskas gemini://tilde.team/~emilis/ -------------- next part -------------- A non-text attachment was scrubbed... Name: naujenai.lt.crt Type: application/pkix-cert Size: 574 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201128/c018 6d84/attachment.cer>
Sorry, I found another certificate on my VPS which matches the fingerprint used by Lagrange browser. So I think I can confirm, that I was NOT MITM-ed and it must be the bug in gmnisrv. I had two sets of certificates, because I ran gmnisrv with a changed configuration. I had attached the other, matching certificate for the curious. ``` $ openssl x509 -noout -fingerprint -sha256 -in naujenai-2.lt.crt SHA256 Fingerprint=95:C3:4B:F2:3A:D2:6F:64:62:71:38:87:5C:E2:B2:51:04:8F:CF:EA:9B: E9:05:A7:C9:91:53:25:FB:0E:35:46 ``` On 11/28/20 6:39 PM, Emilis wrote: > On 11/28/20 5:14 PM, Ben Burwell wrote: >> Those logs do look a little funky, but luckily we don't need to rely on >> IP addresses to check your hypothesis: all you need to do is match the >> fingerprint/hash of the cert being presented by Lagrange with the hash >> of the cert generated on your server. If they don't match, then you have >> definitively been MITM'd. > > I can't match the server certificate to it's browser fingerprint. > > I am not sure I am using the correct methods. > > My Lagrange `.config/lagrange/trusted.txt` has this line: > > ``` > naujenai.lt 1638096010 > 95c34bf23ad26f64627138875ce2b251048fcfea9be905a7c9915325fb0e3546 > > ``` > > I attached my `naujenai.lt.crt` which was generated by gmnisrv. > > > I ran these commands on the certificate file: > > ``` > $ openssl x509 -in naujenai.lt.crt -noout -fingerprint -sha256 > SHA256 > Fingerprint=83:D8:96:B8:83:2B:D7:04:A2:E1:36:78:15:4B:1D:4F:30:A1:13:22:7 9:57:AD:68:A8:70:2B:49:9F:1D:D0:65 > ``` > > ``` > $ openssl x509 -in naujenai.lt.crt -outform DER -out naujenai.lt.der > $ sha256sum naujenai.lt.der > 83d896b8832bd704a2e13678154b1d4f30a113227957ad68a8702b499f1dd065 > naujenai.lt.der > ``` > > Lagrange seems to be using sha256 fingerprints, but I am not a C > developer so I can't be sure: > https://git.skyjake.fi/skyjake/the_Foundation/src/branch/master/src/tlsrequest.c#L310 > > > -- > Emilis Dambauskas > gemini://tilde.team/~emilis/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: naujenai-2.lt.crt Type: application/pkix-cert Size: 574 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201128/20eb 072c/attachment.cer>
It seems there also is an issue with my browser's UI: the warning color on the security icon matched the primary color of the built-in theme I am using: https://github.com/skyjake/lagrange/issues/72#issuecomment-735268218 I didn't notice that Lagrange was actually warning me about the changed certificate. Gemini spec says (4.2): > If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA. I think we would all benefit if someone went through the known browsers, checked how they implement this and published the results. -- Emilis Dambauskas gemini://tilde.team/~emilis/
"Ben Burwell" <gemini at benburwell.com> writes: > On 2020-11-28 at 09:28 -05:00, Emilis <emilis at emilis.net> wrote: >> How would TOFU work for someone out of a country that firewalls the >> internet and can replace all self-signed certificates for port 1965 on >> the fly? > You're right - it wouldn't protect the privacy of people under that > scenario (assuming the state actor is sufficiently motivated to do this > interception/replacement under TOFU constraints). > > I'm not sure what a good solution to this is. One option would be a 'certificate observatory', where various clients around the world submit the fingerprints they receive for various hosts. You can then compare the cert you receive with the consensus of the observatory. This doesn't protect you from MITM, but it makes you aware of it. If you need to *actually* access content without a MITM, you'll need to use TOR or a VPN. That's still true under the CA system; it's just more obvious because your connections fail verification. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it. -- Dogen |
Jason McBrayer <jmcbray at carcosa.net> writes: > One option would be a 'certificate observatory', where various clients > around the world submit the fingerprints they receive for various hosts. > You can then compare the cert you receive with the consensus of the > observatory. This doesn't protect you from MITM, but it makes you aware > of it. If there's a MITM, you cannot be sure the observatory is trusted just by using TOFU.
On Mon, Nov 30, 2020 at 9:51 AM Jason McBrayer <jmcbray at carcosa.net> wrote:
> "Ben Burwell" <gemini at benburwell.com> writes:
> > On 2020-11-28 at 09:28 -05:00, Emilis <emilis at emilis.net> wrote:
> >> How would TOFU work for someone out of a country that firewalls the
> >> internet and can replace all self-signed certificates for port 1965 on
> >> the fly?
>
A more practical version of this scenario is a MITMing corporate firewall.
In general, there is no right of privacy for what you do using your
employer's equipment, at least in the U.S.
> One option would be a 'certificate observatory', where various clients
> around the world submit the fingerprints they receive for various hosts.
> You can then compare the cert you receive with the consensus of the
> observatory. This doesn't protect you from MITM, but it makes you aware
> of it.
>
Unless, of course, the MITMer is aware of the observatory and alters what
you receive from it.
In general, if someone controls *all* your connections to the outside
world, they can make you believe whatever they want, and crypto doesn't
help in the slightest. The reason the Great Firewall of China doesn't
block or MITM outbound VPN connections is that China doesn't want it to:
VPN connections are very expensive in China, so they are generally used
only by foreigners there on business, which China has no desire to alienate
and who are unlikely to have Chinese political motives.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
Mos Eisley spaceport. You will never see a more wretched hive of scum
and villainy --unless you watch the Jerry Springer Show.
--georgettesworld.com
> If you need to *actually* access content without a MITM, you'll need to
> use TOR or a VPN. That's still true under the CA system; it's just more
> obvious because your connections fail verification.
>
> --
> +-----------------------------------------------------------+
> | Jason F. McBrayer jmcbray at carcosa.net |
> | A flower falls, even though we love it; and a weed grows, |
> | even though we do not love it. -- Dogen |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/59d3
856d/attachment-0001.htm>
Warning: uninformed opinions follow; feedback welcome. On Mon, Nov 30, 2020 at 09:51:01AM -0500, Jason McBrayer wrote: >One option would be a 'certificate observatory', where various clients >around the world submit the fingerprints they receive for various >hosts. You can then compare the cert you receive with the consensus of >the observatory. This doesn't protect you from MITM, but it makes you >aware of it. There are multiple solutions, each with different sets of flaws. An observatory's flaws don't necessarily signify that it's a bad idea; they could also signify that it shouldn't be out *only* idea. An idea related to an observatory: I think that it would be awesome if crawlers like GUS saved certs and allowed people to search through them in a variety of ways or over a variety of protocols: Tor, i2p, downloading limited dump over bittorrent...I'm spitballing MITM-resistant protocols. I don't know the "best" ways to go about this while avoiding the negative privacy-related consequences of opening up the index, but offering cert-checking over multiple other MITM-resistent protocols could help vulnerable users who'd like to be extra careful during the first connection. Hmm...Gemini-over-i2p actually sounds *awesome*, especially since the tiny footprint of Gemini pages could pair well with its speed loss. /Seirdy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/425e bff1/attachment.sig>
---
Previous Thread: [ANN] Stream of Consciousness - fancy single-user twtxt frontend in gemini
Next Thread: Standard fingerprint format for TLS certificates